There was an interesting discussion being held on Twitter a day or so ago – the question of designing systems that are “good enough”, or systems that are “perfect”.
I used to believe in the pursuit of perfection in systems, until I realised it was trying to mould engineering concepts to reality, and is therefore an often misguided approach. I also think trying to mould cruel business concepts to reality (i.e., “make it as cheap as possible and hope for the best”) is as equally a misguided approach as a meaningless quest for perfection.
Now, undoubtedly that’ll upset a few people, so I want to lay some ground-work here. When referring to a built system architecture, or even a proposed system architecture:
- “Good enough” should mean “within design specifications”;
- “Good enough” should mean “within acceptable failure tolerances”.
The term “good enough” suffers from, well, a distinct lack of bad press, and rightly so. If anything, what I’m suggesting is that we need to reform the usage of the term. This was perhaps best summarised in a discussion I briefly jumped into on Twitter. Phil Jaenke (aka @rootwyrm) said:
“Good enough” is rarely “good enough.” Instead, it’s “meh, I don’t feel like trying harder.”
That’s actually the core of the problem for me: “good enough” is being abused. Phil’s attitude comes, rightly so, from seeing undoubtedly a long set of examples of something termed as being “good enough” that actually wasn’t. It’s also somewhat reminiscent of that leaked Sun marketing video from a few years criticising a competitor’s systems, with a customer of the competitor repeatedly saying “But good enough is still ‘good’, right?”
I think we need to classify “good enough” solutions that currently exist into three separate categories:
- Those that are genuinely “good enough”.
- Those that are cobbled together/work so long as nothing goes wrong because the person implementing couldn’t do a better job (either out of apathy or time constraints – the reason is irrelevant).
- Those that are not properly specified in the first place.
There’s a lot of systems out there that are genuinely good enough. They should not be disparaged or lumped in with the other two categories described above.
In my experience, the above 3 categories share about a 1/3 split each of the entire pie. So that means there’s a lot of inadequate systems that are classified erroneously as “good enough”.
So, of the above list of three categories, only one is “good enough”. The second category should be rightly described as “not conforming to specifications”, or “incomplete”, if you want to make it short. The third category is “inadequately scoped”.
In reality, no-one should ever attempt to describe something that is incomplete/fails to conform to specifications, or something that was inadequately scoped as being “good enough”.
Good enough should not be a dirty expression.
Now, returning to something I said earlier, about a “meaningless quest for perfection”, I want to qualify that: I don’t mean that a pursuit of perfection is meaningless. However, “perfect” is a nebulous term that can, if misapplied result in significant over-engineering, significantly beyond the desired or required scope. Is this bad? Well, yes, it actually is if it hampers the completion of a project, or causes a significant blow-out in costs.
Misapplied, a quest for perfection can result in a worse system or environment than “good enough” would have delivered. Take Toyota as an example. Toyota have a general rule that if you can see a way to improve efficiency by just a few percent, you should get it implemented. Other car companies won’t shift on anything unless they can see it resulting in a 15 or 20% improvement in the bottom line. Cumulatively though, Toyota builds a more improved environment by allowing “good enough” changes to their system.
Perfection is nice; perfection is sometimes even required, and to be admired when it can be achieved, but if “good enough” is all that is required, then “perfect” may actually be inappropriate.
Next time you see the term “good enough” being bandied around, ask yourself this: is it really “good enough”, or is it incomplete, or inadequately scoped?
Nice…we should realize that not all businesses are NASA, or the NYSE. Tolerance for downtime and data loss will vary from case to case – and are not always none and none. In that sense, the oerational folks (not to mention the ones writing the checks)need to be involved in defining “good enough”.
Good post. Certinaly this topic should be very interesting to any vendor as they try and balance the combination of RFE’s, bug fixes and let’s not forget the occassional innovation. Probably never going to be complete concensus on this but a frank and candid conversation is step one to esuring there is some sense of shared expectations between what we deliver and what you thought you bought. Thanks!