Blog

If I were given the power to strike one word from the lexicon of software projects, it would be the word "DONE". Too often, clients and developers interpret the meaning of the word "DONE" differently and critical misunderstandings arise.

In the most literal sense, software of any significant scope is never "done". There are always bugs. Even if they have not yet been discovered, they exist. There are always enhancements, refinements, improvements (pick your term) that range from "nice to have" to "can't live without". There are always new versions of operating systems, changes to hardware platforms, new standards, etc. that alter the behavior of software and force updates to be necessary. Software is an asset with carrying costs. And in that sense, software is not truly done until the day it is decommissioned and not used anymore.

Developers live in this world. They know implicitly that software is never "done". So when a client asks, "is the software done?" many developers don't know the right thing to say. I suspect the neural connections go something like this:

- "Is the software done?"

- Hmm. Software is never done.

- The client must be asking something else.

- Maybe he's asking if I've finished implementation.

- I have, so I'll say "yes"!

I call this "Programmer Done Syndrome" and it's a significant source of misunderstandings in contract development. Clients will make important decisions based on the developer saying that the software is done. They'll purchase expensive advertising or announce a ship date to their customers. Then, they'll get a release of the software and find out that it doesn't work. They'll say: "you said it was done. Why doesn't it work?" The programmer will say: "I said it was done. I didn't say I had fixed the bugs!"

I know that I'm over-simplifying, but I really have seen variations of this happen too many times to count, sometimes with very serious consequences for all involved.

So how do you avoid these critical misunderstandings in a client / vendor relationship? Training on both sides.

After nearly 20 years in the software development business, I've come to wish that an electrical shock would zap a developer every time he tells a client "it's done". Don't say that. Be more specific. Say: "We have addressed all known requirements. It is now time to enter a testing phase. During testing, you will test and we will test. We will all log issues in our issue tracking software. We will work with you to prioritize the issues. We will focus first on high priority issues, then on medium priority issues, and lastly on low priority issues. At any time during this process, new issues may arise. Those will be immediately logged and prioritized. The software is "done" whenever you decide that the quantity and nature of the remaining issues is sufficient for your specific business purposes."

That's a mouthful, I know. It's a lot easier to say: "it's done". But it's worth the effort to be specific!

On the client side, it's important to first accept the reality that software is never truly done. This is one of the things about software that you can't change. You can only accept it and learn to manage it. Here are a few suggestions:

1) Be as specific as possible when you ask questions. Don't ask: "is it done". Instead, ask "can we burn the DVDs, stick them in boxes, and ship them to the distributor? After we ship, how will we update the software in the field?"

2) Really consider how important a specific issue is to your business before deciding it's critical. If you consider all issues critical, your software may never ship. Microsoft famously shipped a version of Windows with over 50,000 known bugs. That may make you cringe, but their willingness to do so has made them billions of dollars over the years.

3) Budget for maintenance. After 1.0 ships or goes live, there will still be work to do. That's the reality. You need to plan for it and have the budget for it. If you do, it will make it easier to get 1.0 out the door. You can make intelligent decisions about deferring features and issues until a future release.

4) Parallelize what you can. For example, see if you can lock down the graphical assets so you can get started on the product packaging or marketing website while development continues.

5) Timebox development. Ultimately, software is "done" when the client says it is. Set a deadline and stick with it. Please understand, however, that for this to work, you need to be willing to ruthlessly triage the remaining work.

6) Finally, be careful how you communicate with other stakeholders in your organization. When your boss asks, "when will it be done", don't fall into the same trap as your developers!