Iterative, Incremental, and Agile Development
Iterative vs Incremental
These two terms are often confused, but they describe different strategies for managing development:
- Iterative: build a rough version of the whole system, then refine it over multiple passes. Like drafting an essay — you write a rough draft, then revise and polish.
- Incremental: build the system piece by piece, fully finishing one piece before starting the next. Like building with Lego — you complete each module before attaching the next.
Modern processes combine both: building incrementally (feature by feature, delivering a working subset each Sprint) and iteratively (improving each feature over time as feedback arrives).
The Agile Revolution
In February 2001, 17 pioneers representing lightweight methodologies (XP, Scrum, DSDM, Crystal, FDD) met at a ski resort in Snowbird, Utah. They produced one of the most influential single-page documents in software history.
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
The framing is critical. The manifesto does not say processes and tools are worthless — it says that when they conflict, the item on the left takes priority.
| Value | Meaning |
|---|---|
| Individuals & interactions | Process should serve the team, not constrain it. A fool with a tool is still a fool; a brilliant team with a whiteboard can produce better software than a dysfunctional team with the most expensive toolchain. |
| Working software | The primary measure of progress. A perfect specification document with zero lines of working code has delivered zero value. Show working software every ~2 weeks and adapt. |
| Customer collaboration | The client is part of the team, not an adversary to be managed via contract. It is cheaper and faster to course-correct after a 2-week Sprint than after a 2-year Waterfall phase. |
| Responding to change | A plan is a snapshot of what you knew yesterday. If the market has moved or the customer has learned, clinging to the plan is not discipline — it is waste. Architecture must stay modular so change is cheap. |
What Agile Is Not
Agile is frequently misrepresented:
- Agile does not mean zero documentation. It means just enough documentation for the task at hand, prioritising working code over tomes that go out of date the moment they are published.
- Agile does not mean zero planning. Agile teams plan more frequently than Waterfall teams — they just plan in smaller, tighter loops (Sprint Planning every 2 weeks, daily sync) rather than one massive upfront plan.
- Agile does not mean chaos. It requires immense discipline: rigorous testing (often TDD), continuous integration, relentless refactoring, and a commitment to transparency and inspection.
Extreme Programming (XP)
Kent Beck developed XP in the 1990s. The philosophy: take recognised good practices and turn them up to “extreme” levels. XP is focused on technical execution — unlike Scrum, which is a management framework.
Key XP practices:
- Pair Programming: two developers, one keyboard. The driver types; the navigator reviews line by line, spots edge cases, and thinks strategically. Pairs switch roles frequently. Benefits: continuous real-time code review, knowledge sharing, fewer defects. Cost: roughly 15% more person-hours but measurably fewer bugs — typically a net saving when maintenance is accounted for.
- Test-Driven Development (TDD): write the test before the code. Red-Green-Refactor. Covered in depth in the testing notes.
- Continuous Integration: merge to main multiple times a day. Every merge triggers a full automated build and test suite. The team never has a “broken” main branch for more than a few minutes.
- Simple Design: do the simplest thing that could possibly work. YAGNI (You Ain’t Gonna Need It). Resist the temptation to build a hyper-scalable distributed architecture for a product with zero users.
- Refactoring: continuously restructure code to keep it clean, simple, and expressive — enabled by the comprehensive test suite.
Few companies practise pure XP today, but its technical practices (TDD, CI, pair programming, refactoring) are universally recognised and widely adopted in various combinations.
Premature Optimisation and YAGNI
Donald Knuth’s famous observation: “Premature optimisation is the root of all evil” — in programming, at least.
The engineering rule: get correctness first, optimise only when a performance bottleneck is demonstrated by measurement. Guessing where the bottleneck is almost always wrong. Profiling a running system tells you where time is actually spent, and it is rarely where you assumed.
YAGNI (You Ain’t Gonna Need It) is the Agile corollary: only build what is necessary for the current requirement. Adding a caching layer, a message queue, or a microservice architecture “in case we need it later” adds complexity, maintenance burden, and potential bugs for a use case that may never materialise. When you do need it later, you will know exactly what requirements it must satisfy, and you can build it properly.
Expected Learning
- Distinguish iterative from incremental development, and explain how modern processes combine both.
- State the four values of the Agile Manifesto and explain the priority relationship (“over,” not “instead of”).
- Describe at least three XP practices and explain how each addresses a specific software-engineering risk.
- Explain YAGNI and premature optimisation, and give examples of what each guards against.
- Correct common misconceptions about Agile (no documentation, no planning, chaos).
Past Paper Questions
Example Sheet 1, Question 8 directly asks you to apply the Agile Manifesto’s values to a scenario involving a government contract with a fixed-price, fully-specified 500-page document — testing whether you understand that “customer collaboration over contract negotiation” is in direct tension with that model, and how prototyping (Spiral-style) might reconcile both.