Code and fix model- A recipe for disaster

The study of development models cannot be complete unless we include the traditional - code and fix model. It is a model (or rather a lack of model) which is easy, but useless if rapid development is to be achieved. Although no one uses it today, understanding what it was highlights the practicality of the development models we use. So rather this blog should have been titled "benefits of development models"

Here presenting adaptations from the book Rapid Development: Taming Wild Software Schedules by Steve McConnell

If you have not done any project planning or chosen another lifecycle model, then you undoubtedly use this 'model'
Combined with a short-schedule, which is the case most of the times, this model gives rise to code-like-hell approach. The code like hell approach is an approach which makes people work until either they or the project has been finished.

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. You then use whatever combination of informal design, code, debug and test methodologies suits you until you have a product ready to release.

The code and fix model has two advantages. First, it has no overhead: You don't spend nay time on planning, documentation, quality assurance, standered enforcements, or any activities other than pure coding. Since you jump right into coding, you can show signs of progress immediately. Second it requires a very little expertise: anyone who has ever written a computer program is familiar with the code and fix model.

For tiny projects that you intend to throw away 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 projects other than a tiny project, this model is dangerous. It might have no overhead, but it also provides no means of accessing progress- You just code until you are done.
It provides no means of accessing quality or identifying risks. If you discovered three quarters of the way through coding that your whole design approach is fundamentally flawed, you have to throw the work you have done and start over again. Other models would set you up to detect such a fundamental mistake earlier, when it would have been less costly to fix.