Software development methods

Each entry gives the originator, the organising mechanism, and the cost the mechanism imposes. Methods are grouped by mechanism, because two methods with the same mechanism behave the same way under stress, and two methods with the same vocabulary often do not.

1. Phase gates

Mechanism: decrease rework by completing and approving each phase before the next one starts. Information flows forward. A gate is a checkpoint where an artifact gets approved.

Waterfall. Named after the diagram in Winston Royce's 1970 paper, which presented the pure sequential form as the model that does not work and proposed iteration around it. The name survived, the caveat did not. Cost: the requirements must be correct at the start, and the cost of an error grows with the distance to the gate that would have caught it.

V-model. German government standard, early 1990s, also standard in automotive and aerospace. The left arm decomposes requirements into designs. The right arm composes tests that validate each level on the left. Cost: same as waterfall, with the addition that the test plan is fixed early.

Stage-Gate. Robert Cooper, product development rather than software. Each gate is a business decision to continue or stop. Cost: optimises for portfolio decisions rather than for engineering feedback.

ISO/IEC 12207. A process standard rather than a method. It enumerates the processes a software life cycle contains and leaves the ordering open. Cost: it describes, it does not prescribe.

2. Risk-driven iteration

Mechanism: order the work by risk. Do the thing that could kill the project first, at small scale, and use the result to decide the next increment.

Spiral model. Barry Boehm, 1986. Each loop performs objective setting, risk analysis, development, and planning. Prototyping is the standard tool for a high-risk loop. Cost: it requires a team that can assess risk, and it gives no guidance when risks are unclear.

Rational Unified Process (RUP). Rational Software, late 1990s. Four phases (inception, elaboration, construction, transition), each containing iterations, with nine disciplines running across them at varying intensity. Elaboration exists to retire architectural risk. Cost: heavy in artifacts, and often deployed as a waterfall with iteration labels.

Rapid Application Development (RAD). James Martin, early 1990s. Timeboxed iterations with heavy prototyping and user involvement. Cost: works on data-entry and forms applications, degrades on systems with hard algorithmic or performance requirements.

3. Short feedback loops

Mechanism: decrease the interval between an action and the information about whether the action was correct. The agile family sits here. The practices differ; the mechanism is one.

Scrum. Ken Schwaber and Jeff Sutherland, first presented in 1995, with the name taken from Takeuchi and Nonaka's 1986 study of product teams. Fixed-length sprints, a product backlog, three roles, four events. Scrum specifies the container and stays silent on engineering practice. Cost: the silence. A Scrum team with no technical practices produces short cycles of unmaintainable code.

Extreme Programming (XP). Kent Beck, 1996 to 1999. Twelve practices set to maximum intensity. Unlike Scrum, XP prescribes the engineering practice: pairing, test-first, refactoring, continuous integration, collective ownership. Cost: the social practices demand high, sustained cooperation.

Crystal. Alistair Cockburn. A family of methods indexed by team size and criticality, on the principle that a four-person team and a forty-person team need different amounts of ceremony. Cost: it gives you a selection rule rather than a method.

DSDM (later Agile Business Consortium framework). UK consortium, 1994. Timeboxing with MoSCoW prioritisation, where scope flexes and the date does not. Cost: needs a genuinely negotiable scope.

Feature-Driven Development (FDD). Jeff De Luca, 1997, on a Singapore banking project. Build an object model, list the features, then design and build by feature in short cycles, with each class owned by a single developer and chief programmers leading the feature teams. Cost: individual code ownership, which is the opposite of the XP choice.

Shape Up. Ryan Singer at Basecamp, 2019. Six-week cycles, work "shaped" at a fixed level of abstraction before it is handed over, no backlog, and a circuit breaker that kills any project that overruns. Cost: it assumes a team that can refuse work.

4. Flow and batch size

Mechanism: decrease the size of each unit of work and the queue in front of it. Throughput improves because waiting time falls, not because anyone works faster.

Lean software development. Mary and Tom Poppendieck, 2003. Seven principles adapted from Toyota production: eliminate waste, amplify learning, decide late, deliver fast, empower the team, build integrity in, see the whole. Cost: the manufacturing source needs translation, and translations vary.

Kanban. David J. Anderson, formalised around 2010 from work at Microsoft and Corbis. Visualise the work, limit work in progress, manage flow, make policies explicit. No iterations, no prescribed roles. Cost: it changes nothing about how work is done, only how much is done at once.

Continuous Delivery. Jez Humble and David Farley, 2010. Every change goes through an automated deployment pipeline and stays releasable. Trunk-based development and feature flags are the usual enabling practices. Cost: high upfront investment in test automation and deployment infrastructure.

DevOps. Named at the 2009 devopsdays event in Ghent. Removes the handover between the team that writes the code and the team that runs it, so the writers hold the operational consequences. Cost: it is an organisational change wearing a technical name, and it fails when only the tooling is adopted.

Site Reliability Engineering (SRE). Google, practice from the early 2000s, published 2016. Reliability becomes an explicit budget: define a service level objective, spend the error budget on feature velocity, and stop shipping when the budget runs out. Cost: requires measurement infrastructure and an organisation that will honour the stop rule.

5. Correctness before execution

Mechanism: establish correctness by proof or construction rather than by testing. Testing samples the input space. These methods reason over all of it.

Cleanroom. Harlan Mills at IBM, 1980s. Developers do not execute the code they write. Correctness comes from stepwise refinement with formal verification arguments, and a separate team performs statistical testing based on expected usage. Cost: developer discipline and specialised training.

Formal specification languages. Z (Jean-Raymond Abrial, 1977; developed at Oxford), VDM (IBM Vienna), B and Event-B (also Abrial), Alloy (Daniel Jackson, MIT), TLA+ (Leslie Lamport, 1999). The system's properties are written in a mathematical notation and checked by proof or by a model checker. Cost: expressing a real system takes effort, and the proof covers the model rather than the code, unless refinement is carried through.

Correctness by Construction. Praxis (later Altran), using SPARK Ada. Each step preserves a proved property, so defects are prevented rather than found. Cost: restricted language subset, and low tolerance for changing requirements.

Design by Contract. Bertrand Meyer, Eiffel, 1986. Preconditions, postconditions and invariants are part of the code and are checked at runtime or statically. Cost: the contracts must be written and maintained.

6. Process measurement

Mechanism: measure the process, then improve the measured quantity. Assumes the measured quantity predicts the outcome.

CMM and CMMI. Software Engineering Institute, from 1991. Five maturity levels from initial to optimising, assessed by appraisal. Cost: appraisal pressure produces documentation that satisfies the appraisal.

Personal Software Process and Team Software Process. Watts Humphrey, SEI, 1995 and 1999. Individual engineers record time and defect data on their own work and use it to plan. Cost: the data collection burden falls on the individual, and adherence decays without enforcement.

DORA metrics. Accelerate research programme, from 2014. Deployment frequency, lead time for change, change failure rate, and time to restore. Cost: the four metrics measure delivery, and say nothing about whether the delivered thing was worth building.

7. Scaling structures

Mechanism: preserve small-team feedback loops inside a large organisation by fixing the interfaces between teams.

SAFe (Scaled Agile Framework). Dean Leffingwell, 2011. Program increments, release trains, portfolio layer. Cost: reintroduces the coordination overhead the agile methods removed.

LeSS (Large-Scale Scrum). Craig Larman and Bas Vodde. Scrum with multiple teams and one product backlog, adding as little as possible. Cost: requires deep organisational change to work as specified.

Spotify model. Described by Henrik Kniberg in 2012. Squads, tribes, chapters, guilds. Cost: it was a snapshot of one company at one moment, published as a description and adopted as a prescription.

Team Topologies. Matthew Skelton and Manuel Pais, 2019. Four team types (stream-aligned, enabling, complicated-subsystem, platform) and three interaction modes, with Conway's law used deliberately to shape the architecture through the org chart. Cost: it needs authority over the org chart.

8. Specification as the artifact

Mechanism: make an explicit specification the object that is maintained, and derive the implementation from it.

Behaviour-Driven Development (BDD). Dan North, 2006. Acceptance criteria are written in structured natural language (Given/When/Then) and executed as tests. Cost: the scenario layer needs maintenance, and it drifts when nobody reads it.

Domain-Driven Design (DDD). Eric Evans, 2003. A design approach rather than a process. A ubiquitous language shared by domain experts and developers, with bounded contexts separating models that use the same words differently. Cost: it takes sustained access to domain experts.

Spec-Driven Development (SDD). Emerged 2025 for use with AI coding agents. An executable, version-controlled specification is the source of truth, and code is treated as a build output. The standard loop is specify, plan, tasks, implement (GitHub Spec Kit documentation). Amazon Kiro produces requirements.md, design.md and tasks.md, and writes requirements in EARS, a constrained-English requirements template that originated at Rolls-Royce. Tools divide along a rigor spectrum: spec-first (the discipline stops once the agent writes code), spec-anchored (the spec lives alongside the code and tests enforce alignment), and spec-as-source (humans edit only the spec). Cost: validation is the phase most tools leave optional, and static specs drift from the implementation.