Archive for June, 2007
It’s Done™ (a.k.a. it Works™)
Posted in Campfire Stories, The Art of Programming on June 10th, 2007Have you ever had a disagreement about when something is actually done (as opposed to “not done yet”)?
I started learning about “done” when my parents started making me do chores around the house.
Doing dishes: Walk to sink, wash dishes, put in drainer. Done. Am I right? I though I was right.
“Did you empty out the dishpan?” my mom asked.
“No.”
“Well, you’re not done yet.”
Later, I say “now I’m done.”
“Did you wipe down the sink, counters, and stove?”
“That’s part of ‘washing the dishes?’” Even a ten year-old understands the concept of scope creep. The answer was yes but through my push-back I won a change in the name of the task. From then on “Doing the dishes” had to be called “Doing the dishes and cleaning up the kitchen.”
The bottom line: in a team environment the implementer can influence but does not own the determination of when a task is done. Like project scope, doneness is a value negotiated with the customer of the work.
I was recently asked to define “done” in my organization. This is a clear sign that something might be broken. Maybe it just means that there have been recent disagreements about done?
What is Not Done?
I often find that a helpful way to define a positive value is by defining the corresponding negative value.
Not Done is also “it doesn’t work.” To me this is an obvious corollary but I find that this does not occur to some people. The reverse is certainly true.
Not Done is when code “Works on My Machine.” I cringe when I hear “it’s working on my machine” especially since this is typically a response to someone saying “I can’t get it to work” This is ESPECIALLY bad when heard in response to “I can’t get it to build.” When a developer says “it works on my machine” they are really saying:
I do not know what this software depends on.
I do not know what’s involved in moving this software to a clean machine.
I have not checked in all the required code into the source code control system (and I probably don’t know what’s missing).
I do not really care that it does not work on your machine. I’m hoping that’s your problem…
Not Done is when code has not been tested. Untested code does not really work. This is because code that has not been tested invariably has some issues when actually exercised. I consider unit testing the absolute bare minimum level of testing before code can be considered done. An alternative to unit testing? Sure, a full blown test team.
Not done is when code cannot be reliably deployed. This is related to the “it works on my machine” issue. Reliable deployment means the developer has thought about all the steps, interactions and dependencies their code has and has documented them in detail sufficient to allow installation. Maybe the developer even went wild and wrote some install scripts or set up a full featured installer. It could happen.
Documentation
Is documentation required before code can be considered Done? If the code cannot be replicated, tested, or deployed without some written assistance then yes, it cannot be considered done until enough documentation has been written.
I find explaining to a developer that this piece of code is theirs to work on forever and ever until they write enough documentation to hand it off works as a powerful motivator to getting documentation written.
So What does Done mean?
Based on the discussion above I think I’ve outlined my definition of Done:
It has been tested.
It is reproducible and deployable on all supported environments.
It is documented sufficiently.
Most importantly (recalling my experience with the dishes), the customer agrees that it does what they want.