Better Done Than Perfect: Tempering Standards for Software Projects
“Better done than perfect” may not be great advice in jobs like bridge building. No one wants to drive across a bridge that was declared done when it was still buggy.
But what about software development? Developing software is a complex undertaking and one that’s typically deadline driven. It’s impossible to test every conceivable scenario or even to conceive of every conceivable scenario. The result is that mistakes surface, and how serious that is depends on the kinds of mistakes and their impact.
The challenge is to find the balance between speed and quality. I have a friend who develops software for medical instrumentation. He doesn’t rush to declare it done when it’s still bug-infested.
Still, “better done than perfect” is a good reminder that sometimes we set standards or discuss a matter beyond what the situation calls for. It’s easy to let our priorities get out of whack so that we devote much more time and effort to relatively trivial matters than circumstances warrant.
Of course, declaring a project done can be a challenge for perfectionists. If you set excessively high standards, are overly critical of yourself, and are concerned about what other people think, you may not be able to complete some projects at all because they never attain that level of perfection.
Writing is one area where being done can make more sense than being perfect. I became a fan of “better done than perfect” when I discovered I was doing so many successive edits of my writing, striving to get it just right, that it eventually came back to exactly where I started.
I had another “aha” moment when I realized that for all my time-consuming effort, readers would read in mere seconds a sentence I’d slaved over for hours. (And very few of those readers would be likely to stop reading in midsentence and say, “Gee, I’d have liked this sentence better if she’d used a stronger verb.”)
Often, even when there are imperfections, no one notices. And sometimes, having something finished in a workable condition and available for use now is better than having it closer to perfection but taking months longer.
If writing bogs you down as you strive to get it just right, try writing for a while, then put it aside for a day or longer. When you come back to it, you may find that it’s not as bad as you feared.
Whether in writing, software development, or any other undertaking, think about your efforts and the efforts of your team. Think about whether, in the interests of perfection, you sometimes take longer than is necessary.It may be that in certain activities, a BDTP attitude will free you to do more, do it better, and have the greatest overall impact.
