Done

Projects shouldn’t drag on forever. People need to feel that things have finished, goals have been met, work has been completed. Launch parties are nice, even if they’re just 10 minutes of “yay!”. If a project is too big to ever be done, it should be broken up into smaller pieces, some of which can be ‘done’. Done-ness is an important part of a great software development experience. This reminds me of a Pragmatic Programmers column called Cook Until Done

For instance, beginners require simple, context-free rules in order to function in a new environment. They don’t want to see the big picture–it’s overwhelming, confusing, and (to them) irrelevant. Suppose you were giving a recipe to a novice cook. It’s not at all sufficient to say “cook until done,” because the novice has no experience to determine what “done” means. A novice needs to be told to cook it for thirty-five minutes at 350 degrees. No more, no less.

Advanced practitioners, on the other hand, “must” have access to the big picture or they won’t be able to function. If you tell an expert chef to cook anything for exactly thirty-five minutes at precisely 350 degrees they will, at best, ignore you. “Cook until done,” while meaning nothing to a novice, speaks volumes to an experienced chef. It means taking into account the humidity, the condition of this particular batch of ingredients, the vagaries of the equipment in question (that oven always runs hot), the color of the dish, the aroma, and so on.

We won’t claim to be such advanced practitioners of programming that we always know when something is done. In any case, done-ness is in the eye of the beholder, and it’s something that has be negotiated. Which brings me to another quote from that article:

Developing software is largely composed of two activities: learning and communication. Surprised? Those probably aren’t the two chief activities that came to your mind first. But in one form or another, that’s what fills our days. We’re always learning–not just new technology, but the problem domain, the quirks of the users/clients, the characteristics of the evolving system itself. Similarly we’re always communicating: with the machine, with the users, with each other, and sometimes even to a family member who wonders just exactly what it is we do all day.

So we learn, and communicate, and learn some more, and communicate some more, and then we’re done, and we serve some stinky cheese on a platter to celebrate.