Having high quality standards for your project is a matter of practicality, not pride. To understand why, it helps to remember that "bad code" is typically hard to understand, hard to test, hard to change, and hard to reuse. Regardless of how useful your project is to the world right now, these problems will get in the way of its future progress.
Any one of these negative traits of bad code can make a maintainer's job painful, but when you combine all four of them it is like wearing a pair of lead boots while trying to run a marathon. Even if you are capable of supporting your project in its current state, these hindrances will gradually chip away at your ability to be responsive to the needs of your users while simultaneously eating up time and energy that you could be using to improve your project's strengths rather than fighting against its weaknesses. Once you head down this road, your project stops being fun to work on, and starts feeling more like a burden.
Once the impact of low quality code reaches a critical mass, the temptation is great to either let projects stagnate or to attempt the big rewrite with a much stricter focus on quality standards. Unfortunately, neither of these outcomes typically end well for a project's existing community of users, because the road to maintainer burnout is paved with big rewrites.
Some will inevitably take these observations as a cautionary tale, and make a solemn promise to themselves and to the community to establish high quality standards for their project from day one; promising to never ship any bad code in their releases, and to establish strict coding guidelines to keep their projects in ship shape at all times. But anyone who has spent enough time down the rabbit hole can tell you that this doesn't really work, either.
The problem is straightforward: bad code is cheap to write but expensive to maintain, and good code is hard to write but easy to maintain. But in order for code to be good, it needs to be all the things that bad code is not: understandable, testable, changeable, and reusable. There are certainly general strategies that support writing code with these characteristics, but they only solve a small piece of the puzzle. The hard problem is to understand the underlying problem domain and the myriad use cases a workable solution needs to support.
Often, the best way to get the knowledge you need about a complex problem is simply to try out some ideas without much of a concern for quality, and then use what you learned to refine your understanding. This approach helps you generate feedback quickly, and what you lose in code quality up front you gain in knowledge that can be used to write better code later. The important thing is to understand the bargain you are making when doing this, and whether or not the benefits are likely to outweigh the costs.
If you are too strict with your quality standards, you can miss out on healthy experimentation that will improve your project over the long haul, but if you loosen up too much your project will perpetually remain in an experimental state in which none of its code can be trusted. The sweet spot is somewhere between these two extremes, and it pays to actively seek it out rather than just hope to end up there by chance.
Your goal should be to adopt a process that always keep the quality arrow pointing upwards over the long haul, but isn't so brittle as to prevent necessary experimentation and the occasional mistake from happening. We'll now discuss a few specific tactics that can help you achieve that goal.
(rest of essay goes here)
This is a pre-publication excerpt from Practicing Ruby. Thoughts are welcome in comments below, or by email to gregory@practicingruby.com