Fighting Perfectionism—What Is Good Enough?

Perfectionism is a disability deceptively disguised as technical proficiency. It is adds risk to a project while deceiving the developer to believe they are doing the right thing. Where do you draw the line and stop refactoring knowing the code is good enough?

Perfectionism is something I have struggled with for a long time. I often feel dissatisfied with my code because the code is not “just right”. Time and time again I have found myself up against deadlines trying to clean up code that I should have left alone. It is something I have resolved to overcome, and if you suffer from this handicap, I urge you to do the same.

So what is good enough?  How do I know when to stop?

This is a hard question to answer. To get started, we need to know what good software is. I would propose that good software is software that works,  is understandable, maintainable and usable. Given this, the question can be rephrased as four smaller questions:

• Does it work well enough?
• Is it understandable enough?
• Is it maintainable enough?
• Is it usable enough?

Answering these questions should give us a good understanding of what is good enough, and perhaps help us overcome our perfection fetish.

Does it work well enough?

This is a question of requirements. Does the software meet the requirements? Is it stable? Does it meet the defined SLAs? If the answer is to any of these questions is no, then the software is not good enough. If the answer is yes, then we can move on.

Is it understandable enough?

Is the code clear? Can other developers read and make sense of it? Could they pick up development on it if you were hit by a truck?

Is it maintainable enough?

This is where I always get trapped. Can you reasonably modify the code to handle unforseen requirements changes? Is it flexible where the business rules are flexible? If not, can it easily be refactored to be flexible? I have trouble deciding what refactorings to do now, and which to save for later if we need them.

I am often afraid of painting myself into a corner—its a fear of being unable to change when necessary. I recently realized that following good agile practices (TDD, etc…) makes it much harder to paint yourself into a corner. Test coverage and good design allow you to easily refactor yourself out of any pinch.

Remembering to embrace change rather than fear it helps me to put off till tomorrow those things that are not necessary for today.

Is it usable enough?

Can the user accomplish the tasks they need to with the software? Can they do so efficiently and without complaint? An application that is not usable is useless. An app that is overdesigned, however, is wasteful and expensive.

A word of caution

I am not advocating that we develop mediocre software with mediocre design. Please realize that this is written to those developers who have a perfectionist bent, who see great software and great design as something that could be must be improved. Their “good enough” is everyone else’s “great”.

In the competitive world of software development and its pressures to deliver, we must strike a balance between quality and cost. The higher the quality of our code, the longer it will take to develop. In this world, the perfectionist will be forever unhappy with their results given the short time they are allotted. They will never be satisfied, that is, until they can overcome their perfectionism.

Fight Perfectionism! Know when to say when. Then move on.

-Chris