Pragmatic Agile - Done is Better than Perfect

Over my years in software I've heard a lot about using a common sense or pragmatic approach to building systems. I've worked in organizations that borrow heavily from the 37 Signals books Getting Real and Rework, which essentially define pragmatism in the context of shipping software. There's a lot to like about their messages and they're certainly in line with what I've learned and applied since I "joined" the Agile world in 2000. I highly recommend both to anyone who wants to improve how they ship systems.

There's one particular aspect of this approach, though, that can be worrisome.

"Done is better than Perfect."

On its face, this seems like great advice. Don't gold plate the software! Ship something for crying out loud! I won't argue with that recommendation at all. Hell, I give that advice to people myself and even wrote about the evils of Perfection Obsession a while back.

However, you have to be very mindful of what Done means in your context. Another tenet of the 37 Signals approach is "Half, Not Half-Assed". This means simply that you provide partial but meaningful and useful functionality to the consumers of your software which, from a technical standpoint, has quality that's approaching perfect! This is the key part of the message that I have repeatedly seen ignored.

"Done" and "perfect" refer to the scope of the functionality, not its quality.

Quality is non-negotiable. It has to be so good that the people who use the software simply don't notice. It has to be so good that if something does go wrong, it was such a strange corner case that no one could have thought of it beforehand.

One of my key takeaways from Extreme Programming has been that I've learned how to push quality to near zero defects at a reasonable cost. I've been able to work from the assumption that anything greater than zero defects is unacceptable rather than the opposite, where defects are simply expected as a natural part of developing software. Couple that with Exploratory Testing performed by people who really understand how to test software, and again the quality level rises and defect rates decrease even more.

All this is well and good, but what if a new feature of the software passes all of its automated checks, the code has been peer-reviewed and been given all the requisite blessings, it has been thoroughly explored and the testers have become bored, the software is shipped into production, but no one uses that feature? What happens if it doesn't actually do what the users of the system wanted? Was it actually done? It certainly wasn't perfect!

"Done" also needs to contain the notion that there's a valid business reason for delivering the functionality. If even the smallest feature is delivered "just because", then the time, effort and money was wasted.  This doesn't mean, though, that you shouldn't deliver features that haven't been requested by consumers of your system. After all, they may not even realize that they have a need for the feature until they get their hands on it. It does mean, though, that especially in that case you would want to deliver the tiniest possible functionality to expose the assumptions to the real world in order to validate that they were correct.

Shipping something is by far the best way to obtain the feedback required to build systems that people love to use - that delight their customer. Sacrificing quality to do that may seem to help you move faster initially, but it will slow you down over time as the system (and the defect list) grows.

Ship very small slices of functionality as quickly as you can and your market can bear, but do so with the view that the quality of that functionality must be nothing other than "the best".

If you need help doing that, I happen to know a coach... :)