In their pure forms, iterative/incremental and waterfall models are on the opposite ends of software development. In the first approach, it is in the short, repeated cycles (iterations) which involve needs analysis, programming, unit testing and deployment of components that the final product is achieved. It is a process broken down into a number of small portions (increments) before it concludes in ultimate functionality. The second approach is not cyclical, but linear in nature. Every step of software development life cycle, from requirements gathering to production, is carried out only once and leads sequentially to following steps.
In reality, few companies adhere to either of these models in their extreme versions, going more often than not for hybrid or modified approaches. It should not be surprising considering that both iteration and waterfall have their limitations.
Iterative software development is often criticized for allowing developers to fast-track their early-stage concerns, at the level of requirements or design, and proceed without having a clear vision of where they want to arrive. This means less discipline and more chaos, which constitutes a greater burden on key resources, such as time and manpower, as issues that were under-invested at the beginning hit back with a multiplied force. Importantly, when left unresolved early on, they tend to complicate themselves over time. Iterative methods also tend to be less principled when it comes to documentation, which means that plenty of knowledge might be lost in the process.
On the other hand, critics see waterfall software development as too rigid to effectively adjust to demands of many projects, especially if it is hard to predict their full scope/functionality or if they are not very stable by nature. As software products become more and more complex, it is simply hard to predict all problem area at the start of the project. The other thing is that waterfall does not allow teams to learn much along the way – it makes it a hassle to gather practical feedback about particular components of the final product and enhance it by implementing regular corrections. Finally, in waterfall models commitment as to the scope of the tool (made possible by small-size iterations and plenty of feedback) is delayed, giving decision-makers time to choose the most adequate, most market-oriented solution.
Clearly, there is a lot of potential to integrate both approaches into something of a middle road that takes the best practice from waterfall and iteration. The mix could include discipline and documentation integrity that characterizes classic waterfall software development, as well as concentration on conserving resources by doing things right early on. The iterative approach could pitch in by bringing its massive learning value (from processing feedback) and increasing responsiveness to changing business needs when development is still in progress.
You might also read about dedicated teams in software development.
Top comments (0)