The perfect is the enemy of the good.– Voltaire
Motivation to perform to perfection is a strong force in western society. The attitude that we have to be better than anyone else at something, to achieve perfection in our activities, has been a strong force throughout modern history, from the world’s nations down to the individuals which form their bases. And it’s seen every day in projects of all scopes and sizes.
But Voltaire left a message that should be listened to, by everyone on every project – one that is unfortunately ignored by many, to their detriment.
It’s a somewhat heretical thought: What if we don’t have to be perfect? What if we just do good enough to pass? What will that offer us instead of striving to be the best? Well, what it offers is the ability to work more efficiently and still do a proper job of it.
What is good enough?
It’s actually pretty simple. Being good enough is about meeting the needs of the project, rather than the ideals. Some might think it means lacking quality, but it’s really more about balancing quality against the work that actually needs to be accomplished.
For an example of something good enough, one need only recall the 1980s and early 90s, to VHS. In the late 70s and early 80s, it competed against the Betamax standard for home video. However, it won the competition in the end because it was good enough for the average consumer. It was cheap, had acceptable video and audio quality, and was readily available. In contrast, Sony’s Betamax standard, while better quality than VHS, was more expensive and harder to get a hold of. The focus of having a perfect format paradoxically resulted in a product that couldn’t cut it against VHS.
What’s wrong with being perfect?
First of all, perfectionism is procrastination. Say it out loud: perfectionism is procrastination. When you try to be perfect, you get little, if anything, actually accomplished. Planning for perfection leads to a project terminal state known as analysis paralysis – you get so bogged down in the details of what could happen, what could be needed, etc. that you never actually get started at all. And for a project that is in development, perfectionism can lead to endless wanking on a few particular pet tasks of the developers, as they keep trying to make those parts they’re working on better and better. At first it may look like progress, but at some point, those constant attempts at improvement return no value at all.
On the other hand, aiming for Good Enough just gets the job done. In planning, you focus on what the requirements are, no more, no less, and how to meet them simply and efficiently. No worrying about edge cases or making things bulletproof or endlessly customizable – meet the core needs and be done with it. As for development, it should be simple enough to test against the plan to see if a task is met. Once it is, you move on to the next one, and stop worrying about the one you just finished. The work goes by faster, and you accomplish more.
Another issue with perfection is that not everyone agrees on what perfect means, in the context of the project. It’s very easy to end up with a camel, when what you want is a horse, because everyone thinks that the perfect quadruped needs this or that or the other thing. It’s a very subjective concept, as opposed to achieving good enough. Not to say that good enough isn’t subjective itself, but it’s a much easier target to hit and reach consensus on, and if you plan well, it can be objectively determined whether or not something is Good Enough based on project goals, client needs, and metrics collected during the planning and development stages of a project.
Determining what is good enough
There are three simple questions you can ask:
Is it simple? That is to say, is the design simple and can be picked up by the developers without much work? If the design and implementation is simple, it’s easier to make any needed changes later, while still fulfilling the current requirements now.
Does it work acceptably well? If it’s easy for the end user to figure out, and does the job without raising problems the user can’t handle, it’s good.
Does it cover all the bases? It should meet the project requirements, with a minimum of additional features tacked on. Wherever additional things are added, it should either be because of (legitimately) changing requirements, or because those features are required by the features which do meet project requirements.
There are some clear advantages to aiming for good enough rather than for perfection. You’ll be more efficient while still providing a proper job well done. It’s not necessary to provide all the bells and whistles so long as you meet the goals of your project, so don’t try for it! Success comes from getting the job done right, not done perfect. And good enough is doing it right.
The greatest enemy of a good plan is the dream of a perfect plan.– Karl von Clausewitz
Pulled from the archives. Originally published on July 1, 2010.