Working or Done

Last night I woke up in the middle of the night, worried about a specific problem in our model layer that I was sure was going to cause problems if it wasn’t resolved. I tossed and turned until about 2:30 when I got out of bed and went downstairs and fired up the laptop.

So we had a working model class, with no behavioral problems observable in the application. Sounds OK. Then I looked at the class… WOW – what a mess. Internally, it had a crap ton of spaghetti in private methods, and it implemented a serialization interface that should have been in a different class, and it had knowledge of other classes that should have been encapsulated, etc. There were no appropriate tests written. A mess.

When I queried the developer, he believed that he had done a great thing by getting it “done” on time. He also believed that he had been authorized to take these shortcuts to make the deadline. What I reflected, was that there were no comments in the code with TODO or HACK labeled for the necessary rework, nor was there any explanation of what he had done.

This prompted me to write this explanation:

The difference between “working” and “done” is:

• working software exhibits the appropriate behavior and information.
• done means that it is fully implemented, according to accepted patterns, standards, and fulfilling stated and implied requirements.

Benefits of Working
In general, I am in favor of delivering working software as quickly as possible. But working is a different state from done. Working allows us to demonstrate the software and gather feedback. Working allows us to start implementing related capabilities. Working may represent our first attempt at meeting the requirements, and it allows us to prove that we understood them correctly. I need working software capabilities.

Working is not the final state. After we have got to working, gathered feedback, understood requirements, we have gained knowledge about the problem. Sometimes done is actually less than the initial working state, because along the way, we found a way to simplify. Sometimes done is more than the initial workings state, because we realized that our design or requirements missed some elements of the solution. Rarely if ever, is the initial working state, done.

Definition of Done
Done on different teams may imply QA involvement, unit test coverage, code review, documentation, every software organization has their criteria for done.

Each of us have a personal definition of done as well. This definition is informed by out experience, and our preferences, and more likely than not, our self-discipline and our integrity. One reason that we sometimes struggle with done, is that we don’t always establish that the “team’s” done state is different from our “personal” done states, and even after we establish it, our personal done state is hard to displace – we always revert to the familiar if there is not a powerful reason to change.

As a software developer, when I substitute some state of working for the established done state, I am in effect saying, “What they don’t know won’t hurt them, at least until I have moved on…”

Bossery and Technical Debt
Sometimes, a technical lead, architect or pointy haired boss will ask us to not get to done. They ask us to stop at the working stage. They insist that we don’t have time to get to done. I have done it myself. Bosses and leaders need to be mindful of the schedule and cost of product delivery. They may choose to stop at working. It is their prerogative. It truly is a pay me now or pay me later proposition. If you are one of those guys who is cool with that, then no worries. If you have a bad reaction to this idea, you have two options: 1) adjust your initial working state to be closer to done, and your estimates accordingly. 2) when asked to stop at working, capture a log of the time/effort it would take to get to done, and keep a running total of how much “technical debt”, the project is carrying. Push that log towards the lead every time they ask you to stop at working. Let them put their reputation at stake, let the contemplate the cost. Make them sign the log – if they refuse, you have a different problem – they may less transparent towards your customer regarding the decisions they are making.

Conclusion
Remember, you are at least partly responsible for the state a software product is in when you finish a sprint, release, or project. Working is a useful state on the way to done. Some developers (and bosses) are so focused on hitting the done state, that they forget that feedback that comes after done is costly. Some customers have trouble differentiating between working and done, so you have to constantly remind them that you are showing them a “preview” and it is not complete.