Iterative and incremental development

Iterative and incremental development is a software development approach in which a product is built over a series of short cycles rather than in a single pass. Each cycle produces a working – if incomplete – version of the system, and the next cycle refines or extends it. The approach pairs two complementary ideas that are often conflated.

Iteration is the repetition of a development cycle to improve something that already exists. The team builds a version, learns from it, and rebuilds the same part better. Increment is the addition of new capability on top of what already works. The two are orthogonal: a team can iterate without adding features, by refining one piece, or add increments without iterating, by extending without revisiting. Iterative and incremental development does both. It grows the system by adding pieces while repeatedly revising the pieces already in place.

Piecemeal growth is the process of design and implementation in which software is embellished, modified, reduced, enlarged, and improved through a process of repair rather than of replacement.

– Richard P Gabriel
_Patterns of Software_ (1996)

Gabriel’s piecemeal growth is the same instinct that underpins "worse is better". A simple implementation that works and can be revised tends to outlast a complete design that cannot.

Contrast with single-pass approaches

Iterative and incremental development stands against the plan-driven, single-pass approaches it grew out of. The waterfall model and big design up-front attempt to specify, design, and build a system in one linear sequence. The same contrast appears in deployment and migration, where big bang cutovers are set against phased, incremental transitions, and in AI-assisted coding, where spec-driven development risks the same single-pass failure mode if a specification is implemented in one batch rather than broken into small, independently verified steps. The argument against single-pass working is empirical. Requirements are hard to get right in advance, and the later a flaw is found the more it costs to fix. Short cycles with working software at the end of each one surface flaws early, when they are cheap.

A longer history than agile

Iterative and incremental development is now associated with agile software development, but the practice predates the agile movement by decades. Craig Larman and Victor Basili, in their 2003 survey Iterative and Incremental Development: A Brief History, trace the approach back to the 1950s and 1960s. IBM’s STRETCH computer, the SAGE air-defense system, and NASA’s Project Mercury and Atlas programs all used iterative, time-boxed development. Winston Royce’s 1970 paper, often cited as the origin of waterfall, in fact proposed an iterative model with feedback loops between phases and an explicit recommendation to do a "first pass" through the whole process before refining it. Barry Boehm formalized the idea as the spiral model in 1988, framing each iteration around risk reduction. In the 1990s, Grady Booch, Ivar Jacobson, and James Rumbaugh consolidated their object-oriented design processes into the Unified Process, whose best-known implementation is the Rational Unified Process (RUP). In 1991 James Martin formalized rapid application development (RAD), a prototype-led method for business systems that sat firmly in the same iterative tradition. Agile methods – Scrum, Extreme Programming, and the rest – are the most recent and most visible expression of the same tradition, codified around shared values rather than a single process.

Practices that make it work

Iterative cycles are only as good as the technical practices that keep the growing codebase healthy. Each iteration that revises existing code is an act of refactoring. Each iteration that adds a working build depends on continuous integration to keep the pieces coherent and continuous delivery to keep them releasable. A walking skeleton is a common way to start. A thin end-to-end slice is built first, and the full functionality is fleshed out around it, incrementally. Gall’s law states the same point at the level of systems. A complex system that works is invariably found to have evolved from a simple system that worked.

Iteration is distinct from prototyping. A prototype is a disposable artifact for answering a design question. Iterative and incremental development builds the product itself, in small, permanent steps.

Pitfalls

Iteration without architectural guidance can turn into unbounded rework. Without a sense of where the system is heading, each cycle adds a patch on the last, and the codebase drifts toward a big ball of mud. Uncontrolled increments invite scope creep, and revisions made under time pressure accumulate technical debt that erodes the very adaptability the approach was meant to preserve. The mitigation is not more up-front design but better feedback. An architectural spine established early, such as a walking skeleton or the evolvability guarded by fitness functions, continuous integration to catch drift as it happens, and a willingness to refactor every cycle rather than only when something breaks.

See also

References

  • Larman, Craig; Basili, Victor R. (2003). Iterative and Incremental Development: A Brief History. IEEE Computer, 36(6), pp. 47–56.
  • Royce, Winston W. (1970). Managing the Development of Large Software Systems. Proceedings of WESTCON.
  • Boehm, Barry W. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(5), pp. 61–72.
  • Gabriel, Richard P. (1996). Patterns of Software. Oxford University Press.