But then the project includes unknown amounts of unplanned work to diagnose the failure and to rectify the defect. And then to test again. Absorbing this unplanned work is one reason for a project to exceed budget and deliver late, and it is built in to the way that many projects are planned.
In the paper Royce presents the waterfall process only as a straw man. Few readers seem to have reached the next 11 pages where he explains what to do instead. This oversight fed into an extensive literature of software engineering texts that promoted the waterfall as an ideal to which projects should aspire.
Of course, some projects that claim to follow the waterfall (or similar) are successful. On close examination they demonstrate Ivan Moore's dictum that all programming is iterative, whether it is meant to be or not.
A year before Royce's paper Niklaus Wirth and Alan Perlis had argued at the second NATO software engineering conference over the merits programming by interacting with a computer.
Wirth worried that 'the facility of quick response leads to sloppy working habits'. Perlis countered that 'conversational techniques aid and abet systems programming and improve the programmer. By its very nature, programming is done by development... conversational systems permit programmers to work from the top down and to compute even with incomplete specifications.'
Computing with incomplete specifications was part of Royce's antidote to the waterfall. He recommends beginning to test before implementation is complete, beginning implementation before design is complete and similarly with design, analysis and requirements gathering.
He also suggests building an architecturally complete but restricted functionality version of the system very early in a project - not for use, although it should be used, but to learn from. This resonates with Fred Brookâs observation of 1975 that the question 'is not whether to build a pilot system and throw it away. You will do that. Hence plan to throw one away; you will, anyhow.'
For a long time the party of Wirth, and sympathisers, won the argument, and the industry embarked on a programme of software engineering based on the waterfall and working out programs away from a computer and trying to get everything right first time. That can be made to work, but only at great expense. Much more often it fails, also at great expense.
In 1995 Ward Cunningham published his Episodes pattern language of competitive development: fast delivery, high quality, flexible planning. Also in 1995 Ken Schwaber first published a description of the Scrum development process: incremental delivery, iterative development, self-organising teams.
Episodes found new impetus as extreme programming and the agile community came into being (adopting that name in 2001). What the agile community has done is to rediscover, codify and make repeatable those early observations regarding the successful way to develop software - as opposed to the way that folks at the NATO conferences thought should be successful.
Perlis' conversational notion of development is manifested at every level in agile development. Through test-driven development programmers converse with the code; through pair programming, with one another; through the planning game with business stakeholders; through early and often releases, with users; and so on.
The common thread through all agile processes is feedback and closed-loop control. Rather than trying to nail down requirements, or designs, or plans, an agile team creates these artefacts at quality but with limited scope, in functionality, or time, then iterates to cover larger scope.
These are the behaviours that truly reduce risk in the development of software, as opposed to things that look as if they should reduce risk. They also produce more accurate reporting of status, better cost control and quicker return on investment.
A project could spend six months attempting to analyse requirements and design a solution, and a year implementing that, or it could implement the most interesting feature in two weeks and put it in the hands of a user and learn something.
Truly, there is, almost, nothing new under the sun. As Sir Anthony Hoare said in his Turing Award address, if we could only learn the right lessons from the successes of the past we would not need to learn from the failures. Agile development is a huge step in that direction.
Keith Braithwaite MBCS, is Head of Zuhlke Engineering's Centre for Agile Practice.
