Rapid iteration in software development means performing short, repeated development cycles based on a set pattern. A two-week development cycle is an example of a rapid iteration. Using iterative software development cycles that incrementally build the system is one of the primary principles of agile software development.
In agile, the primary benefit of rapid iteration is the ability to review and validate user requirements. By using short development cycles, you add the ability to become “agile” and change those requirements in future iterations based on ongoing customer input.
The short development cycle naturally presents a challenge to the quality assurance side of building and maintaining software, as there simply isn't enough time to test everything. Another challenge is that agile teams might not include full-time testers to carry out a comprehensive regimen of tests. Such problems can be resolved with a mix of good design practices and agile testing techniques, which, when combined with a short development cycle, will result in increased product quality, early defect detection, and reduced cost. Various case studies have shown a substantial improvement in quality and customer satisfaction.
In this article, I will explore how rapid iteration can improve software quality through reduced complexity and early defect detection.
Iterative, Incremental Development Challenges
The two terms “iteration” and “increment” are often used together, as in this quote from Ken Schwaber's The Enterprise and Scrum : “Scrum makes workload management possible through iterative, incremental development.” “Iterative” in this context refers to following a pattern of steps in repeated cycles for fixed durations, while “incremental” refers to the actual building of the software application—or, in a broader sense, the entire project, since you can also be building tests, documentation, and so on.
Incremental development is challenging if each programmer is left to his own devices with no set structure, pattern, or common development practice, and the project becomes a series of ad-hoc pieces meshed together only through the heroic, often last-minute actions of the programmers. Complexity greatly increases, and the code becomes harder to decipher as the architecture of the project varies widely based on too many random variables. For example, even simple things like documentation and comments can become difficult (or impossible) to decipher if there is no standard practice for them.
Incremental design therefore has the ability to become disasterous. Change is required if the developers want to keep their jobs. So, how can change be introduced frequently through the rapid, iterative approach without one change trashing another?
The first solution to this problem is for agile developers to use incremental—or, as Martin Fowler prefers, “evolutionary”—design.
Agile software methodologies describe incremental design, such as this example from Tips from Scrum a nd XP from t he Trenches: “This means keeping the design simple from the start and continuously improving it, rather than trying to get it all right from the start and then freezing it.”
“Incremental design” simply means designing as you go. This approach upholds agile principles, since valuable time and resources are not wasted up front documenting future changes that may never be implemented anyway or may be unwanted once they are implemented. I recommend Martin Fowler's “ Is Design Dead .” Here are some bullet points:
- Using patterns will allow the software to evolve in a common way.
- Using frameworks and resuable components will yield simplicity and flexibility.
- Enable good testing practices.
A rapidly iterative and incremental workflow provides the proper framework for this type of development strategy, as continuous improvement is built into the workflow in a couple different ways— improving not just through coding but through code review/rewrite,