Originally published by Robert Beisert at fortcollinsprogram.robert-beisert.com

CS 101 – Development Models

We have discussed development of software from the point of view of the programmer and the whole lifecycle. However, we should also look at how this development appears at the management level.


This is the most hated development model, and rightly so.

This development model assumes that we take each stage on in one go, work through it completely, and then move on. This means that we do analysis, design, implementation, and testing exactly once. On a flowchart, this resembles a waterfall.

Unfortunately, life is not so simple. We often have to deal with changing requirements (which changes Analysis and Design), changing tools (implementation), and changing solutions to respond to errors (testing). Waterfall makes no allowances for this.

Further, this is vulnerable to “analysis paralysis”. The larger the problem, the more time it takes to analyze it. As such, this model can hold up development for months or years, ultimately killing the project in its infancy.

Incremental Model

It is often possible to break the waterfall up into a series of steps. We can then work through a bunch of “mini waterfalls” on our way to the solution. This is the incremental model, as each mini-waterfall brings us closer to the planned solution.

The downside to this model is that it requires a lot of analysis before it can begin. This can also lead to analysis paralysis.

Recursive (evolutionary) Model

Sometimes, you don’t really know what your product will look like when it’s all done. Perhaps you’re developing a new technology, or trying to be ready for changes in the market.

We can handle these problems by working on a small problem, evaluating it when it’s done, then adding to it. This resembles the concept of biological evolution in that we don’t have a detailed plan to start with, and the program gets more complex as it goes along.

This suffers from lack of planning and, consequently, lack of predictability. Furthermore, there is no guarantee that the product will be in any way useful.

Agile Model

Agile tries to take the best aspects of the above models and combine them into one. The principle is to create a basic plan, break it into incremental pieces, order these pieces in terms of priority, and recursively add them to the final product.

In addition, Agile development breaks each development phase into a short “sprint” of (usually) about two weeks. This allows programmers to take on bite-sized tasks and see them through without being bogged down in the full system detail. It also allows the team to adapt to new requirements or new discoveries more readily, as they don’t invest large blocks of time into irrelevant tasks.

The downside to Agile development is the time spent in meetings, which are held on daily, weekly, sprint-ly, and quartly bases. Further, strict adherence to a particular Agile framework can require extensive study and attention to detail just to operate.