Skip to content
Software Architecture Guide

Iterative and Incremental Development

Explanation

Section titled “Explanation”

Incremental development builds and delivers a product in complete pieces. The team finishes one piece before moving to the next. The sculpting analogy shows this: an incremental sculptor picks one element of the sculpture and works on it until it is finished.

Combining iterative and incremental work lets teams deliver value early, get feedback, and adapt. The feedback arrives while the work is still going on, not at the end.

Growth by repair, not replacement

Christopher Alexander contrasts two ways to build. Large-lump development rests on replacement. Piecemeal growth rests on repair. Software teams can grow a system step by step and repair what exists.

Alexander also criticizes master plans. They tend to be rigid and become outdated, because users’ needs change over time.

Keeping order while growing

Growth without care can erode a system into a Big Ball of Mud (see the article of that name). Avoiding this takes a permanent commitment to consolidation and refactoring. Refactoring means restructuring existing code to improve it (see Refactoring). It is the main way programmers keep order from inside a system.

YAGNI and evolutionary design

YAGNI is the rule of not building what you do not need yet. Evolutionary design lets the design grow with the system. The two enable each other. Refactoring does not violate YAGNI, because it keeps the code malleable. Self-testing code is one practice that makes this work.

Example

Section titled “Example”

A team builds an online booking tool. In the first cycle, it delivers one complete, tested feature: search and book. Customers try it and ask for an easier date picker. The next cycle improves the date picker and adds a second complete feature, cancel booking. Between cycles, the team cleans up the code so the new feature fits the existing structure instead of being bolted on.

Trade-offs

Section titled “Trade-offs”

Growing in small steps gives early feedback, but it needs discipline. Without a permanent commitment to consolidation and refactoring, the system can erode into a Big Ball of Mud. Refactoring costs effort. That effort is justified because it keeps the code malleable, and it does not violate YAGNI. Master plans avoid repeated rework but become outdated as needs change.

Each cycle delivers a complete piece, gathers feedback, and consolidates before the next.

Diagram source 
flowchart LR
 A[Build a complete piece] --> B[Deliver it]
 B --> C[Get feedback]
 C --> D[Refactor and consolidate]
 D --> A

Checks

Section titled “Checks”
  • The document or team process describes delivering features as complete pieces and gathering feedback after each one.
  • Refactoring and consolidation are planned as ongoing work, not left for later.
  • The team relies on self-testing code so refactoring stays safe and the code stays malleable.
Section titled “Related”

Sources

Section titled “Sources”