As Ed Yourdon described in an article in IEEE Software, you can discipline yourself to write software that’s good enough-good enough for your users, for future maintainers, for your own peace of mind.
Before we go any further, we need to qualify what we’re about to say. The phrase “good enough” does not imply sloppy or poorly produced code. All systems must meet their user’s requirements to be successful. We’re simply advocating that users be given an opportunity to participate in the process of deciding when what you’ve produced is good enough.
Involve Your Users in the Trade-Off
The scope and quality of the system you produce should be specified as part of that system’s requirements.
Make Quality a Requirements Issue
Often you’ll be in situations where trade-offs are involved. Surprisingly, many users would rather use software with some rough edges today than wait a year for the multimedia version. Many IT departments withe tight budgets would agree. Great software today is often preferable to perfect software tomorrow. If you give your users something to play with early, their feedback will often lead you to a better eventual solution.
Know When to Stop
In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them. You sketch out an overall shape, paint the underlying environment, then fill in the details. You constantly step back with a critical eye to view what you’ve done. Every now and then you’ll throw a canvas away and start again.
But artists will tell you that all the hard work is ruined if you don’t know when to stop. If you add layer upon layer, detail over detail, the painting becomes lost in the paint.
Don’t spoil a perfectly good program by over-embellishment and over-refinement. Move on, and let your code stand in its own right for a while. It may not be perfect. Don’t worry: it could never be perfect.