The Different Kinds of Done
Jan 24, 2009 16:11

In my experience in software development, I've noticed that "Done" can mean different things to different people. "Done" is a popular word on software projects, but it's actually hard to pin down. Real production software in the real world is rarely "Done" in the way that we think of "Done," like a baked cake is "Done" or a manufactured item is "Done". Software is more like a book or an album or a movie - read a writer's blog or listen to a director's DVD commentary, and you'll discover that their work is usually delivered when they just can't stand to edit it anymore, and/or their time and money have run out - and hopefully it's "good enough" to go out into the world.

The trouble is, business people and managers often think of "Done" in the manufactured-like-a-car way, while software developers often see "Done" in the it-works-well-enough-so-kick-it-out-the-door way. This can lead to trouble - especially if, as often happens, a developer agrees to a strict date for their work to be "Done" or - more disastrously - there's a condition like payment or vacation time that depends on the work being "Done".

In software projects, it's good to keep clear the differences between "Feature Complete", "Done", and "Live":

  1. "Feature Complete" means all the big pieces of the project are in place, users can navigate through the site without dead links and perform most if not all actions without bringing up errors. There still may be layout issues, typos, unhandled exceptional cases, performance issues, badly migrated data, etc.

  2. "Done" actually means all of the obvious issues that aren't covered in (1) above have been addressed. Hackers, idiots, testers, and a million monkeys on keyboards shouldn't be able to corrupt the data or break into anything. The workflow and layout is all perfect and all of the pieces are the way that they're supposed to be. Every aspect of the application is covered by automated tests and is thoroughly documented.

  3. "Live" means that the application is actually out in front of the real world and paying customers. It actually runs correctly enough to be worthwhile to support and host.

One of the big issues in software projects is the unexpectedly huge difference between "Feature Complete" and "Done". Progress on a software project is often an "S" curve - slow to get started, rapid progress in the middle, and then slow to finish. "Feature Complete" is at the point where the rapid progress slows down, while "Done" is the top line that may never actually be reached.

Often, programmers consider "Feature Complete" as "Done" - the software does what it's supposed to do. This can lead to frustration with management or customers, since from their point of view the application may have loose ends or missing polish. Programmers see all of the complicated work that went into the core algorithms, the security model, the application logic, and all of that, and often get annoyed when management or customers complain about the wrong shade of green in a banner or type nonsense data into a form and get an error.

Often developers will tell management that the software will have "all of the pieces in place" by a certain date, which means "Feature Complete", while management will think that they mean every last detail will be attended to.

A big headache time for all people involved in a project is the last slow top part of the S curve, where the program seems almost ready but the list of problems or fixes that still need to be addressed seems to just keep getting bigger. The programmers, just having finished pushing hard to get to "Feature Complete" are often exhausted and ready for praise, payment, and maybe a vacation. However, because of the different understandings of "done," this most difficult part of the project hasn't been considered in the budget or time planning, and management is frustrated that everything has slowed down and is taking longer than it should.

In the old days of putting software on a disc and into a box, you had to hit "Done" type 2 (or at least get really close to it) before going live (type 3). Nowadays, with most software hosted on the web and easy to update and fix, applications go "Live" before they're really "Done", since changes are easy to make and getting things in front of the world is a great way to see what works.

Developers need to understand that "Done" often means more than having all of the basic features in place, while those who manage or employ them should know that software is never done.

Previous:
Giles Bowkett's RubyFringe presentation
Oct 01, 2008 18:14
Next:
Yeah I Use Tables For Layout, So Sue Me
Feb 02, 2009 22:25