When is software done?
These thoughts were originally posted at http://ardentdev.com in 2011. I’ve moved them here in order to repurpose that domain for a software development podcast.
Are you done yet? Such a simple question…
Earlier in my career I worked on a project that went into production with what I would consider a less than optimal set of internal admin tools. We deployed it and handed it over to the client’s internal team where it stayed live but untouched. After a year in prod, I got an email from the client asking how to cancel a subscription. Apparently someone had signed up and wanted out but was unwilling or unable to use the self-serve features.
The building of software is a funny thing. You can be busy in most professions. You can have more work to do than you can possibly get done. You can have unrealistic deadlines. But you can achieve an outcome, mark it complete, and move on. Software is strange because there are different definitions of done and even when you think it’s done, it probably isn’t. Software components run for months or years with bugs, inconsistencies, performance problems, and security vulnerabilities.
Software developers are accustomed to being asked “when will you be done?” But the question presupposes a shared understanding of what “done” means. Different definitions of done can lead stakeholders to be disappointed in the progress and predictability of software teams. Managers recently promoted from the technical ranks may not have learned to factor in time for tasks beyond the initial code-and-test cycles.
We’ve all seen developers declare a piece of work complete because it compiles or because it ran once with some sample data without crashing. Computer science courses even encourage that behaviour with a constant barrage of coding assignments that are immediately discarded. Eventually professional developers learn the difference between code that runs and code that’s done.
Let’s explode that word done into some more granular stages:
1. The code is written
2. The code is tested
3. The functionality is documented
4. The code is secure, scalable, fault tolerant, and reliable
5. The code is ready to deploy
6. The code is in production
7. The code is no longer being updated (enhancements and/or bug fixes)
8. The code is no longer supported
9. The code is no longer being used
So, are you done yet?