We’re on the verge of a 1.0 release. Hours of planning, designing and coding over the past few weeks have produced a usable product, and we’ll be launching this week. Along with the _other_ priority I’ve had over the past nine months, it’s been, uh, a bit of a tough go. Deadlines and constraints have a funny way of eliciting a sort of desperate creativity. As they say in the business, “shipping a 1.0 product isn’t going to kill you, but it will try.”:

Writing code for the first time is usually a painfully clumsy experience — sketchy objects, redundant variables, wantonly inefficient loops. I’m keenly aware that there are thousands of people who can code better than I can; I imagine them standing over my shoulder, quietly shaking their heads. As I started writing significant portions of the code, I heard these words bubble up from the back of my mind:

Give yourself permission to do it wrong the first time.

So I did. One ugly portion at a time: design, build, test, demo, refine. Once it was good enough (read: _barely working_), move on to the next piece: design, build, test, demo, refine. After a while, it became test, demo, refine, refine, refine. Then: refine, refine, refine, refine, refine. Suddenly it occurs to you in the middle of a demo: wow, everything just worked.

That’s how we did it. We didn’t write any requirements-gathering documents. We didn’t build out a massive infrastructure. There were no draconian change processes or review committee meetings. Just a few clever ideas and a lot of “getting real”:

Doing it all wrong — that’s exactly how we’re going to ship on Friday.

2 thoughts on “Permission

Comments are closed.