The “code-and-fix” approach to software development is not a proper life cycle (see later this unit). Code-and-fix development occurs when software engineers come together with a vague set of requirements and start producing software, fixing it, and changing it until the correct product appears.
This is the simplest way to produce software and is invariably how every programmer learns to program. But for anything other than small software projects, code-and-fix is a disaster for a number of reasons:
There is no way to estimate time scales or budgets.
There is no assessment of possible risks and design flaws: you may come close to a finished product only to find an insurmountable technical problem that sets the whole project back.
We only mention the code-and-fix approach in the context of life cycle models since it is a base-line the model which we should avoid. From a software engineer's point of view, code-and-fix is a worst-case scenario.
Many project failures resulted from the inability to scale the techniques employed when developing small software systems to handle larger, more complex systems.
These problems were largely due to the lack of any framework for the planning and organization of software development projects.
Although some software projects were organized, these were often the more successful ones, it was the luck of the draw whether a project manager had good intuitions for software development, and whether or not problems arose due to misunderstandings between the customers and the developers of the system.
Likewise, there were no clear methods to monitor whether a system was soon to go over budget or miss deadlines.
From some of these problems, we can see that at some stage the system developers attempted (not always successfully) to understand the requirements for the new system.
We can now include it in our diagram of the process of these specified requirements for the new system: