The code-and-fix model is a model that is seldom useful, but it is nonetheless common, so I'd like to discuss it. If you haven't explicitly chosen another lifecycle model, you're probably using code-and-fix by default. If you haven't done much project planning, you're undoubtedly using code-and-fix. Combined with a short schedule, code-and-fix gives rise to the code-like-hell approach described earlier.
CROSS-REFERENCE
Code-and-fix is commonly combined with commitment-based development approaches. For details, see An Alternative Rapid-Development Strategy, An Alternative Rapid-Development Strategy.
When you use the code-and-fix model, you start with a general idea of what you want to build. You might have a formal specification, or you might not. You then use whatever combination of informal design, code, debug, and test methodologies suits you until you have a product that's ready to release. Figure 7-3 illustrates this process.
Figure 7-3. The code-and-fix model. Code-and-fix is an informal model that's in common use because it's simple, not because it works well.
The code-and-fix model has two advantages. First, it has no overhead: you don't spend any time on planning, documentation, quality assurance, standards enforcement, or any activities other than pure coding. Since you jump right into coding, you can show signs of progress immediately. Second, it requires little expertise: anyone who has ever written a computer program is familiar with the code-and-fix model. Anyone can use it.
For tiny projects that you intend to throw away shortly after they're built, this model can be useful—for small proof-of-concept programs, for short-lived demos, or throwaway prototypes.
For any kind of project other than a tiny project, this model is dangerous. It might have no overhead, but it also provides no means of assessing progress; you just code until you're done. It provides no means of assessing quality or identifying risks. If you discover three-quarters of the way through coding that your whole design approach is fundamentally flawed, you have no choice but to throw out your work and start over. Other models would set you up to detect such a fundamental mistake earlier, when it would have been less costly to fix.
In the end, this lifecycle model has no place on a rapid-development project, except for the small supporting roles indicated.