COVER FEATURE Iterative and Incremental Development: A Brief History

Although many view iterative and incremental development as a modern practice, its application dates as far back as the mid-1950s. Prominent -engineering thought leaders from each succeeding decade supported IID practices, and many large projects used them successfully.

Craig s agile methods become more popular, opment” merely for rework, in modern agile meth- Larman some view iterative, evolutionary, and ods the term implies not just revisiting work, but Valtech incremental software development—a also evolutionary advancement—a usage that dates cornerstone of these methods—as the from at least 1968. Victor R. A “modern” replacement of the waterfall Basili model, but its practiced and published roots go back PRE-1970 University of decades. Of course, many software-engineering stu- IID grew from the 1930s work of Walter Maryland dents are aware of this, yet surprisingly, some com- Shewhart,1 a quality expert at Bell Labs who pro- mercial and government organizations still are not. posed a series of short “plan-do-study-act” (PDSA) This description of projects and individual con- cycles for quality improvement. Starting in the tributions provides compelling evidence of iterative 1940s, quality guru W. Edwards Deming began and incremental development’s (IID’s) long exis- vigorously promoting PDSA, which he later tence. Many examples come from the 1970s and described in 1982 in Out of the Crisis.2 Tom Gilb3 1980s—the most active but least known part of and Richard Zultner4 also explored PDSA applica- IID’s history. We are mindful that the idea of IID tion to software development in later works. came independently from countless unnamed pro- The X-15 hypersonic jet was a milestone 1950s jects and the contributions of thousands and that project applying IID,5 and the practice was consid- this list is merely representative. We do not mean ered a major contribution to the X-15’s success. this article to diminish the unsung importance of Although the X-15 was not a software project, it is other IID contributors. noteworthy because some personnel—and hence, We chose a chronology of IID projects and IID experience—seeded NASA’s early 1960s Project approaches rather than a deep comparative analy- Mercury, which did apply IID in software. In addi- sis. The methods varied in such aspects as iteration tion, some Project Mercury personnel seeded the length and the use of time boxing. Some attempted IBM Federal Systems Division (FSD), another early significant up-front specification work followed by IID proponent. incremental time-boxed development, while others Project Mercury ran with very short (half-day) were more classically evolutionary and feedback iterations that were time boxed. The development driven. Despite their differences, however, all the team conducted a technical review of all changes, approaches had a common theme—to avoid a sin- and, interestingly, applied the Extreme Pro- gle-pass sequential, document-driven, gated-step gramming practice of test-first development, plan- approach. ning and writing tests before each micro-increment. Finally, a note about our terminology: Although They also practiced top-down development with some prefer to reserve the phrase “iterative devel- stubs.

0018-9162/03/$17.00 © 2003 IEEE Published by the IEEE Computer Society June 2003 47 The recollections of Gerald M. Weinberg, Another 1960s reference comes from Robert 8 “We were doing who worked on the project, provide a win- Glass: dow into some practices during this period. In incremental a personal communication, he wrote: It is the opinion of the author that incremental development as development is worthwhile, [it] leads to early as 1957, in We were doing incremental development as a more thorough system shakedown, avoids Los Angeles, under early as 1957, in Los Angeles, under the direc- implementer and management discouragement. the direction of tion of Bernie Dimsdale [at IBM’s Service Bureau Corporation]. He was a colleague of THE SEVENTIES Bernie Dimsdale John von Neumann, so perhaps he learned it In his well-known 1970 article, “Managing the [at IBM’s there, or assumed it as totally natural. I do Development of Large Software Systems,” Service Bureau remember Herb Jacobs (primarily, though we Winston Royce shared his opinions on what would Corporation].” all participated) developing a large simulation become known as the , expressed for Motorola, where the technique used was, within the constraints of government contracting as far as I can tell, indistinguishable from XP. at that time.9 Many—incorrectly—view Royce’s When much of the same team was reassem- paper as the paragon of single-pass waterfall. In bled in Washington, DC in 1958 to develop Project reality, he recommended an approach somewhat Mercury, we had our own machine and the new different than what has devolved into today’s Share Operating System, whose symbolic modifi- waterfall concept, with its strict sequence of cation and assembly allowed us to build the system requirements analysis, design, and development incrementally, which we did, with great success. phases. Indeed, Royce’s recommendation was to Project Mercury was the seed bed out of which do it twice: grew the IBM Federal Systems Division. Thus, that division started with a history and tradition of If the computer program in question is being incremental development. developed for the first time, arrange matters so All of us, as far as I can remember, thought that the version finally delivered to the customer waterfalling of a huge project was rather stupid, for operational deployment is actually the second or at least ignorant of the realities… I think what version insofar as critical design/operations areas the waterfall description did for us was make are concerned. us realize that we were doing something else, something unnamed except for “software devel- Royce further suggested that a 30-month project opment.” might have a 10-month pilot model and justified its necessity when the project contains novel ele- The earliest reference we found that specifically ments and unknown factors (hardly a unique case). focused on describing and recommending iterative Thus, we see hints of iterative development, feed- development was a 1968 report from Brian Randell back, and adaptation in Royce’s article. This iter- and F.W. Zurcher at the IBM T.J. Watson Research ative feedback-based step has been lost in most Center.6 M.M. Lehman later described Randell and descriptions of this model, although it is clearly not Zurcher’s work and again promoted iterative devel- classic IID. opment in his September 1969 internal report to What did Royce think about the waterfall ver- IBM management on development recommenda- sus IID when he learned of the latter approach? tions:7 In a personal communication, Walker Royce, his son and a contributor to popular IID meth- The basic approach recognizes the futility of sep- ods in the 1990s, said this of his father and the arating design, evaluation, and documentation paper: processes in software-system design. The design process is structured by an expanding model He was always a proponent of iterative, incre- seeded by a formal definition of the system, which mental, evolutionary development. His paper provides a first, executable, functional model. It is described the waterfall as the simplest description, tested and further expanded through a sequence but that it would not work for all but the most of models, that develop an increasing amount of straightforward projects. The rest of his paper function and an increasing amount of detail as to describes [iterative practices] within the context how that function is to be executed. Ultimately, of the 60s/70s government-contracting models (a the model becomes the system. serious set of constraints).

48 Computer This was an ironic insight, given the influence this boxed iterations of about six months each. paper had as part of the bulwark promoting a strict There was still a significant up-front specifi- The first major sequential life cycle for large, complex projects. cation effort, and the iteration was longer The next earliest reference comes from Harlan than normally recommended today. Although documented Mills, a 1970s software-engineering thought leader some feedback-driven evolution occurred in IBM FSD IID who worked at IBM FSD. In his well-known “Top- the requirements, O’Neill noted that the IID application was Down Programming in Large Systems,” Mills pro- approach was also a way to manage the com- the life-critical 11 moted iterative development. In addition to his plexity and risks of large-scale development. command and advice to begin developing from top-level control Also in 1972, an IBM FSD competitor, structures downward, perhaps less appreciated was TRW, applied IID in a major project—the control system for the related life-cycle advice Mills gave for building $100 million TRW/Army Site Defense soft- the first US Trident the system via iterated expansions:10 ware project for ballistic missile defense. The submarine. project began in February 1972, and the … it is possible to generate a sequence of interme- TRW team developed the system in five iter- diate systems of code and functional subspecifica- ations. Iteration 1 tracked a single object, and tions so that at every step, each [intermediate] by iteration 5, a few years later, the system was system can be verified to be correct… complete. The iterations were not strictly time boxed, and there was significant up-front specifi- Clearly, Mills suggested iterative refinement for cation work, but the team refined each iteration in the development phase, but he did not mention response to the preceding iteration’s feedback.12 avoiding a large up-front specification step, did not As with IBM FSD, TRW (where Royce worked) specify iteration length, and did not emphasize was an early adopter of IID practices. Indeed, Barry feedback and adaptation-driven development from Boehm, the originator of the IID in the each iteration. He did, however, raise these points mid-1980s, was chief scientist at TRW. later in the decade. Given his employment at IBM Another mid-1970s extremely large application FSD, we suspect Mills’s exposure to the more clas- of IID at FSD was the development of the Light sic IID projects run there in the early 1970s influ- Airborne Multipurpose System, part of the US enced his thought, but we could not confirm this Navy’s helicopter-to-ship weapon system. A four- with colleagues. year 200-person-year effort involving millions of Early practice of more modern IID (feedback-dri- lines of code, LAMPS was incrementally delivered ven refinement with customer involvement and in 45 time-boxed iterations (one month per itera- clearly delineated iterations) came under the lead- tion). This is the earliest example we found of a ership of Mike Dyer, Bob McHenry, and Don project that used an iteration length in the range of O’Neill and many others during their tenure at IBM one to six weeks, the length that current popular FSD. The division’s story is fascinating because of IID methods recommend. The project was quite the extent and success of its IID use on large, life- successful: As Mills wrote, “Every one of those critical US Department of Defense (DoD) space and deliveries was on time and under budget.”13 avionics systems during this time. In 1975, Vic Basili and Joe Turner published a The first major documented IBM FSD applica- paper about iterative enhancement that clearly tion of IID that we know of was in 1972. This was described classic IID:14 no toy application, but a high-visibility life-critical system of more than 1 million lines of code—the The basic idea behind iterative enhancement is to command and control system for the first US develop a software system incrementally, allowing Trident submarine. O’Neill was project manager, the developer to take advantage of what was being and the project included Dyer and McHenry. learned during the development of earlier, incre- O’Neill conceived and planned the use of IID mental, deliverable versions of the system. (which FSD later called “integration engineering”) Learning comes from both the development and on this project; it was a key success factor, and he use of the system, where possible. Key steps in the was awarded an IBM Outstanding Contribution process were to start with a simple implementa- Award for the work. (Note that IBM leadership vis- tion of a subset of the software requirements and ibly approved of IID methods.) iteratively enhance the evolving sequence of ver- The system had to be delivered by a certain date sions until the full system is implemented. At each or FSD would face a $100,000 per day late penalty. iteration, design modifications are made along The team organized the project into four time- with adding new functional capabilities.

June 2003 49 The paper detailed successful IID applica- not in iteration—i.e., that development is done in Tom Gilb tion to the development of extendable com- an open loop, rather than a closed loop with user introduced the pilers for a family of application-specific feedback between iterations. The danger in the programming languages on a variety of hard- sequence [waterfall approach] is that the project terms “evolution” ware architectures. The project team devel- moves from being grand to being grandiose, and and “evolutionary” oped the base system in 17 iterations over 20 exceeds our human intellectual capabilities for to the process months. They analyzed each iteration from management and control. lexicon. both the user’s and developer’s points of view and used the feedback to modify both the And perhaps reflecting several years of seeing IID language requirements and design changes in in action at FSD, Mills asked, “...why do enter- future iterations. Finally, they tracked mea- prises tolerate the frustrations and difficulties of sures, such as coupling and cohesion, over the mul- such [waterfall] development?” tiple iterations. In 1977, FSD incorporated the Trident IID In 1976, Tom Gilb published Software Metrics approach, which included integrating all software (coining the term), in which he discussed his IID components at the end of each iteration into its practice—evolutionary —and software-engineering practices—an approach introduced the terms “evolution” and “evolution- McHenry dubbed “integration engineering.” Some ary” to the process lexicon. This is the earliest book Trident team members and Mills were key advisers we could find that had a clear IID discussion and in this incorporation effort.16 Integration engi- promotion, especially of evolutionary delivery:3 neering spread to the 2,500 FSD software engi- neers, and the idea of IID as an alternative to the “Evolution” is a technique for producing the waterfall stimulated substantial interest within appearance of stability. A complex system will be IBM’s commercial divisions and senior customer most successful if it is implemented in small steps ranks and among its competitors. and if each step has a clear measure of successful Although unknown to most software profes- achievement as well as a “retreat” possibility to a sionals, another early and striking example of a previous successful step upon failure. You have the major IID success is the very heart of NASA’s space opportunity of receiving some feedback from the shuttle software—the primary avionics software real world before throwing in all resources system, which FSD built from 1977 to 1980. The intended for a system, and you can correct possi- team applied IID in a series of 17 iterations over 31 ble design errors… months, averaging around eight weeks per itera- tion.17 Their motivation for avoiding the waterfall The book marked the arrival of a long-standing life cycle was that the shuttle program’s require- and passionate voice for evolutionary and iterative ments changed during the software development development. Gilb is one of the earliest and most process. Ironically (in hindsight), the authors sound active IID practitioners and promoters. He began almost apologetic about having to forego the the practice in the early 1960s and went on to “ideal” waterfall model for an IID approach: establish several IID milestones. His material was probably the first with a clear flavor of agile, light, Due to the size, complexity, and evolutionary and adaptive iteration with quick results, similar [changing requirements] nature of the program, it to that of newer IID methods. was recognized early that the ideal software devel- By 1976, Mills had strengthened his IID message:15 opment life cycle [the waterfall model] could not be strictly applied...However, an implementation Software development should be done incremen- approach (based on small incremental releases) tally, in stages with continuous user participation was devised for STS-1 which met the objectives by and replanning and with design-to-cost program- applying the ideal cycle to small elements of the ming within each stage. overall software package on an iterative basis.

Using a three-year inventory system project as a The shuttle project also exhibited classic IID prac- backdrop, he challenged the idea and value of up- tices: time-boxed iterations in the eight-week range, front requirements or design specification: feedback-driven refinement of specifications, and so on. ...there are dangers, too, particularly in the con- The first IID discussion in the popular press that duct of these [waterfall] stages in sequence, and we could find was in 1978, when Tom Gilb began

50 Computer publishing a column in the UK’s Computer Weekly. a synonym for waterfall during this period The column regularly promoted IID, as well as evo- suggests its unquestioned dominance. The IID practice lutionary project management and delivery. In his Contrast this to its qualified use in the 1990s, 6 April 1978 column, Gilb wrote, “sequential life cycle” or “iterative life of evolutionary cycle.”) prototyping was Management does not require firm estimates of In 1982, William Swartout and Robert commonly used completion, time, and money for the entire pro- Balzer argued that specification and design in 1980s efforts ject. Each [small iterative] step must meet one of have a necessary interplay, and they promoted to create artificial the following criteria (priority order): either (a) an iterative and evolutionary approach to give planned return on investment payback, or, if and development.23 intelligence impossible, then (b) give breakeven (no loss); or, at The same year also provided the earliest ref- systems. least, (c) some positive user benefit measurably; or, erence to a very large application successfully at least (d) some user environment feedback and built using evolutionary prototyping, an IID learning. approach that does not usually include time- boxed iterations. The $100 million military com- Another discussion of incremental development, mand and control project was based on IBM’s although published in 1984, refers to a System Customer Information Control System technology.24 Development Corp. project to build an air defense In 1983, Grady Booch published Software system, which began in 1977 and finished in 1980. Engineering with Ada,25 in which he described an The project combined significant up-front specifi- iterative process for growing an object-oriented sys- cations with incremental development and builds. tem. The book was influential primarily in the DoD Ostensibly, the project was meant to fit within DoD development community, but more for the object- single-pass waterfall standards, with testing and oriented design method than for its iterative advice. integration in the last phase. Carolyn Wong com- However, Booch’s later 1990s books that covered ments on the unrealism of this approach and the IID found a large general audience, and many first team’s need to use incremental development:18 considered or tried iterative development through their influence. The [waterfall] model was adopted because soft- The early 1980s was an active period for the ware development was guided by DoD stan- (attempted) creation of artificial intelligence systems, dards… In reality, software development is a expert systems, and so on, especially using Lisp complex, continuous, iterative, and repetitive machines. A common approach in this community process. The [waterfall model] does not reflect this was the IID practice of evolutionary prototyping.26 complexity. In another mid-1980s questioning of the sequen- tial life cycle, Gilb wrote “Evolutionary Delivery THE EIGHTIES versus the ‘Waterfall Model.’” In this paper, Gilb In 1980, Weinberg wrote about IID in “Adaptive promoted a more aggressive strategy than other IID Programming: The New Religion,” published in discussions of the time, recommending frequent Australasian Computerworld. Summarizing the (such as every few weeks) delivery of useful results article, he said, “The fundamental idea was to build to stakeholders.27 in small increments, with feedback cycles involv- A 1985 landmark in IID publications was ing the customer for each.” A year later, Tom Gilb Barry Boehm’s “A Spiral Model of Software wrote in more detail about evolutionary develop- Development and Enhancement” (although the ment.19 more frequent citation date is 1986).28 The spiral In the same year, Daniel McCracken and Michael model was arguably not the first case in which a Jackson promoted IID and argued against the “stul- team prioritized development cycles by risk: Gilb tifying waterfall” in a chapter within a software and IBM FSD had previously applied or advocated engineering and design text edited by William variations of this idea, for example. However, the Cotterman. The chapter’s title, “A Minority spiral model did formalize and make prominent the Dissenting Position,” underscored the subordinate risk-driven-iterations concept and the need to use position of IID to the waterfall model at the time.20 a discrete step of risk assessment in each iteration. Their arguments continued in “Life-Cycle Concept In 1986, Frederick Brooks, a prominent soft- Considered Harmful,”21 a 1982 twist on Edsger ware-engineering thought leader of the 1970s and Dijkstra’s late 1960s classic “Go To Statement 1980s, published the classic “No Silver Bullet” Considered Harmful.”22 (The use of “life cycle” as extolling the advantages of IID:29

June 2003 51 Nothing in the past decade has so radically attention to high risks and the core architecture in The Cleanroom changed my own practice, or its effectiveness the early iterations. [as incremental development]. Bill Curtis and colleagues published a particu- method larly agile-relevant paper during this decade,32 incorporated Commenting on adopting a waterfall process, reporting results on research into the processes that evolutionary Brooks wrote: influenced 19 large projects. The authors identified development that the prescriptive waterfall model attempted to Much of present-day software acquisition pro- satisfy management accountability goals, but they with more formal cedure rests upon the assumption that one can did not describe how projects successfully ran. The methods of specify a satisfactory system in advance, get paper also noted that successful development specification bids for its construction, have it built, and emphasizes a cyclic learning process with high and proof. install it. I think this assumption is fundamen- attention to people’s skills, common vision, and tally wrong, and that many software acquisi- communication issues, rather than viewing the tion problems spring from that fallacy. effort as a sequential “manufacturing process.” As the authors state, Perhaps summing up a decade of IID-promoting messages to military standards bodies and other The conclusion that stands out most clearly from organizations, Brooks made his point very clear in our field study observations is that the process of his keynote speech at the 1995 International developing large software systems must be treated, Conference on : “The water- at least in part, as a learning and communication fall model is wrong!” process. In 1986, David Parnas and Paul Clements pub- lished “A Rational Design Process: How and Why In 1987, as part of the IBM FSD Software to Fake It.”30 In it, they stated that, although they Engineering Practices program, Mills, Dyer, and believe in the ideal of the waterfall model (thorough, Rick Linger continued the evolution of IID with correct, and clear specifications before develop- the Cleanroom method, which incorporated evo- ment), it is impractical. They listed many reasons, lutionary development with more including (paraphrased) of specification and proof, reflecting Mills’s strong mathematical influences.33 • A system’s users seldom know exactly what By the late 1980s, the DoD was experiencing they want and cannot articulate all they know. significant failure in acquiring software based on • Even if we could state all requirements, there the strict, document-driven, single-pass waterfall are many details that we can only discover model that DoD-Std-2167 required. A 1999 once we are well into implementation. review of failure rates in a sample of earlier DoD • Even if we knew all these details, as humans, projects drew grave conclusions: “Of a total $37 we can master only so much complexity. billion for the sample set, 75% of the projects • Even if we could master all this complexity, failed or were never used, and only 2% were used external forces lead to changes in require- without extensive modification.”34 Consequently, ments, some of which may invalidate earlier at the end of 1987, the DoD changed the water- decisions. fall-based standards to allow IID, on the basis of recommendations in an October 1987 report from and commented that for all these reasons, “the pic- the Defense Science Board Task Force on Military ture of the software designer deriving his design in Software, chaired by Brooks. The report recom- a rational, error-free way from a statement of mended replacing the waterfall, a failing approach requirements is quite unrealistic.” on many large DoD projects, with iterative devel- In 1987, TRW launched a four-year project to opment: build the Command Center Processing and Display System Replacement (CCPDS-R), a command and DoD-Std-2167 likewise needs a radical overhaul control system, using IID methods. Walker Royce to reflect modern best practice. Draft 2167A is a described the effort in 60 pages of detail.31 The step, but it does not go nearly far enough. As team time-boxed six iterations, averaging around drafted, it continues to reinforce exactly the doc- six months each. The approach was consistent ument-driven, specify-then-build approach that with what would later become the Rational lies at the heart of so many DoD software prob- (to which Royce contributed): lems….

52 Computer In the decade since the waterfall model was devel- described the Evo method, distinguished by oped, our discipline has come to recognize that frequent evolutionary delivery and an empha- Tom Gilb’s [development] requires iteration between the sis on defining quantified measurable goals Principles of designers and users. and then measuring the actual results from each time-boxed short iteration. Software Finally, in a section titled “Professional Humility Engineering and Evolutionary Development” (humility to 1990 TO THE PRESENT Management was accept that the 2167’s goals—get the specifications By the 1990s, especially the latter half, pub- the first book with accurate without incremental implementation and lic awareness of IID in software development substantial chapters feedback—was not possible), the report stated: was significantly accelerating. Hundreds of books and papers were promoting IID as their dedicated to Experience with confidently specifying and main or secondary theme. Dozens more IID IID discussion painfully building mammoths has shown it to be methods sprang forth, which shared an in- and promotion. simplest, safest, and even fastest to develop a com- creasing trend to time-boxed iterations of one plex software system by building a minimal ver- to six weeks. sion, putting it into actual use, and then adding In the 1970s and 1980s, some IID projects functions [and other qualities] according to the still incorporated a preliminary major specification priorities that emerge from actual use. stage, although their teams developed them in iter- Evolutionary development is best technically, ations with minor feedback. In the 1990s, in con- and it saves time and money. trast, methods tended to avoid this model, preferring less early specification work and a Both DoD overseers and contractors often view stronger evolutionary analysis approach. the updated DoD-Std-2167A, released in February The DoD was still experiencing many failures with 1988, as the epitome of a waterfall specification. “waterfall-mentality” projects. To correct this and Yet, its authors actually wanted it to be an amend- to reemphasize the need to replace the waterfall ment (hence the A) for life-cycle neutrality that model with IID, the Defense Science Board Task allowed IID alternatives to the waterfall: Force on Acquiring Defense Software Commercially, chaired by Paul Kaminski, issued a report in June This standard is not intended to specify or dis- 1994 that stated simply, “DoD must manage pro- courage the use of any particular software devel- grams using iterative development. Apply evolu- opment method. The contractor is responsible for tionary development with rapid deployment of selecting software development methods (for initial functional capability.” example, rapid prototyping) that best support the Consequently, in December 1994, Mil-Std-498 achievement of contract requirements. replaced 2167A. An article by Maj. George Newberry summarizing the changes included a sec- Despite this intent, many (justifiably) interpreted tion titled “Removing the Waterfall Bias,” in which the new standard as containing an implied prefer- he described the goal of encouraging evolutionary ence for the waterfall model because of its contin- acquisition and IID:36 ued document-driven milestone approach. Ironically, in a conversation nearly a decade later, Mil-Std-498 describes software development in one the principal creator of DoD-Std-2167 expressed or more incremental builds. Each build implements regret for creating the strict waterfall-based stan- a specified subset of the planned capabilities. The dard. He said that at the time he knew of the sin- process steps are repeated for each build, and within gle-pass document-driven waterfall model, and each build, steps may be overlapping and iterative. others he questioned advised it was excellent, as did the literature he examined, but he had not heard Mil-Std-498 itself clearly states the core IID prac- of iterative development. In hindsight, he said he tices of evolving requirements and design incre- would have made a strong recommendation for IID mentally with implementation: rather than the waterfall model. In 1988, Gilb published Principles of Software If a system is developed in multiple builds, its Engineering Management, the first book with sub- requirements may not be fully defined until the stantial chapters dedicated to IID discussion and final build…. If a system is designed in multiple promotion.35 In it he reiterated and expanded on builds, its design may not be fully defined until the the IID material from Software Metrics. Gilb final build.

June 2003 53 Meanwhile, in the commercial realm, Jeff tion of Peter Coad and Jeff De Luca, the team res- XP garnered Sutherland and Ken Schwaber at Easel Corp. urrected it and ran it as a successful IID project. significant public had started to apply what would become DeLuca created an overall iterative process descrip- known as the Scrum method, which tion, Feature-Driven Development (FDD), that also attention because employed time-boxed 30-day iterations. The incorporated ideas from Coad.43 of its emphasis on method took inspiration from a Japanese IID In 1998, the Standish Group issued its widely communication, approach used for nonsoftware products at cited “CHAOS: Charting the Seas of Information simplicity, and Honda, Canon, and Fujitsu in the 1980s; Technology,” a report that analyzed 23,000 pro- testing, and its from Shashimi (“slices” or iterations); and jects to determine failure factors. The top reasons from a version of Scrum described in 1986.37 for project failure, according to the report, were sustainable A 1999 article described their later refine- associated with waterfall practices. It also con- developer-oriented ments to Scrum.38 cluded that IID practices tended to ameliorate the practices. In January 1994, a group of 16 rapid appli- failures. One of the report’s key conclusions was cation development (RAD) practitioners met to adopt IID: in the UK to discuss the definition of a stan- dard iterative process to support RAD devel- Research also indicates that smaller time frames, opment. The group drew inspiration from James with delivery of software components early and Martin’s RAD teachings. Martin, in turn, had taken often, will increase the success rate. Shorter time his inspiration from the time-boxing work at frames result in an iterative process of design, pro- Dupont, led by Scott Shultz in the mid-1980s. The totype, develop, test, and deploy small elements. RAD group’s process definition would eventually become the Dynamic Systems Development In 2000, DoD replaced Mil-Std-498 with Method (DSDM), an IID method that predictably another software acquisition standard, DoD had more early advocates in Europe and has since 5000.2, which again recommended adopting evo- spread.39 lutionary acquisition and the use of IID: In the early 1990s, a consortium of companies began a project to build a new-generation There are two approaches, evolutionary and sin- Canadian Automated Air Traffic Control System gle step [waterfall], to full capability. An evolu- (CAATS) using a risk-driven IID method. The pro- tionary approach is preferred. … [In this] ject, under the process leadership of Philippe approach, the ultimate capability delivered to the Kruchten, used a series of six-month iterations, rel- user is divided into two or more blocks, with atively long by today’s standards. The project was increasing increments of capability...software a success, despite its prior near-failure applying a development shall follow an iterative spiral devel- waterfall approach.40 opment process in which continually expanding In the mid-1990s, many contributors within software versions are based on learning from ear- Rational Corp. (including Kruchten and Walker lier development. Royce) and its clients created the Rational Unified Process, now a popular IID method. A 1995 mile- In 2001, Alan MacCormack reported a study of stone was the public promotion of the daily build key success factors in recent projects; first among and smoke test, a widely influential IID practice these was adopting an IID life cycle:44 institutionalized by Microsoft that featured a one- day micro-iteration.41 Now there is proof that the evolutionary approach In 1996, Kent Beck joined the Chrysler C3 pay- to software development results in a speedier roll project. It was in this context that the full set of process and higher-quality products. […] The iter- XP practices matured, with some collaboration by ative process is best captured in the evolutionary Ron Jeffries and inspiration from earlier 1980s delivery model proposed by Tom Gilb. work at Tektronix with Ward Cunningham. XP went on to garner significant public attention In February 2001, a group of 17 process because of its emphasis on communication, sim- experts—representing DSDM, XP, Scrum, FDD, plicity, and testing, its sustainable developer- and others—interested in promoting modern, sim- oriented practices, and its interesting name.42 ple IID methods and principles met in Utah to dis- In 1997, a project to build a large logistics system cuss common ground. From this meeting came the in Singapore, which had been running as a water- Agile Alliance (www.agilealliance.org) and the now fall project, was facing failure. With the collabora- popular catch phrase “agile methods,” all of which

54 Computer apply IID. And in 2002, Alistair Cockburn, one of References the participants, published the first book under the 1. W. Shewhart, Statistical Method from the Viewpoint new appellation.45 of Quality Control, Dover, 1986 (reprint from 1939). 2. W.E. Deming, Out of the Crisis, SPC Press, 1982; n a typical quip, H.L. Mencken said, “For every reprinted in paperback by MIT Press, 2003. complex problem, there is a solution that is sim- 3. T. Gilb, Software Metrics, Little, Brown, and Co., I ple, neat, and wrong.” In the history of science, 1976 (out of print). it is the norm that simplistic but inferior ideas first 4. R. Zultner, “The Deming Approach to Quality Soft- hold the dominant position, even without sup- ware Engineering,” Quality Progress, vol. 21, no. 11, porting results. Medicine’s four humors and related 1988, pp. 58-64. astrological diagnosis and prescription dominated 5. W.H. Dana, The X-15 Lessons Learned, tech. report, Europe for more than a millennium, for example. NASA Dryden Research Facility, 1993. Software development is a very young field, and 6. B. Randell and F.W. Zurcher, “Iterative Multi-Level it is thus no surprise that the simplified single-pass Modeling: A Methodology for Computer System and document-driven waterfall model of “require- Design,” Proc. IFIP, IEEE CS Press, 1968, pp. 867- ments, design, implementation” held sway during 871. the first attempts to create the ideal development 7. M.M. Lehman, “The Programming Process,” inter- process. Other reasons for the waterfall idea’s early nal IBM report, 1969; reprinted in Program Evolu- adoption or continued promotion include: tion—Processes of Software Change, Academic Press, 1985. • It’s simple to explain and recall. “Do the 8. R. Glass, “Elementary Level Discussion of Com- requirements, then design, and then imple- piler/Interpreter Writing,” ACM Computing Surveys, ment.” IID is more complex to understand and Mar. 1969, pp. 64-68. describe. Even Winston Royce’s original two- 9. W. Royce, “Managing the Development of Large iteration waterfall immediately devolved into Software Systems,” Proc. Westcon, IEEE CS Press, a single sequential step as other adopters used 1970, pp. 328-339. it and writers described it. 10. H. Mills, “Debugging Techniques in Large Systems,” • It gives the illusion of an orderly, accountable, Software Productivity, Dorset House, 1988. and measurable process, with simple docu- 11. D. O’Neill, “Integration Engineering Perspective,” J. ment-driven milestones (such as “requirements Systems and Software, no. 3, 1983, pp. 77-83. complete”). 12. R.D. Williams, “Managing the Development of Reli- • It was promoted in many software engineering, able Software,” Proc. Int’l Conf. Reliable Software, requirements engineering, and management ACM Press, 1975, pp. 3-8. texts, courses, and consulting organizations. 13. H. Mills, “Principles of Software Engineering,” IBM It was labeled appropriate or ideal, seemingly Systems J., vol. 19, no. 4, 1980, pp. 289-295. unaware of this history or of the statistically 14. V. Basili and J. Turner, “Iterative Enhancement: A significant research evidence in favor of IID. Practical Technique for Software Development,” IEEE Trans. Software Eng., Dec. 1975, pp. 390- This brief history shows that IID concepts have 396. been and are a recommended practice by promi- 15. H. Mills, “Software Development,” IEEE Trans. nent software-engineering thought leaders of each Software Eng., Dec. 1976, pp. 265-273. decade, associated with many successful large pro- 16. D. O’Neill, “The Management of Software Engi- jects, and recommended by standards boards. neering,” IBM Systems J., vol. 19, no. 4, 1980, pp. Yet, even though the value of IID is well known 421-431. among literate, experienced software engineers, 17. W. Madden and K. Rone, “Design, Development, some commercial organizations, consulting com- Integration: Space Shuttle Flight Software System,” panies, and standards bodies still promote a docu- Comm. ACM, Sept. 1984, pp. 914-925. ment-driven single-pass sequential life cycle as the 18. C. Wong, “A Successful Software Development,” ideal. We conclude with this recommendation: In IEEE Trans. Software Eng., no. 3, 1984, pp. 714- the interest of promoting greater project success 727. and saving taxpayer or investor dollars, let’s con- 19. T. Gilb, “Evolutionary Development,” ACM Soft- tinue efforts to educate and promote the use of ware Eng. Notes, Apr. 1981, p. 17. IID methods. 20. W.W. Cotterman et al., eds., and

June 2003 55 Design: A Foundation for the 1980’s, North-Hol- ment,” Pattern Languages of Program Design, vol. land, 1981. 4, 1999, pp. 637-651. 21. D. McCracken and M. Jackson, “Life-Cycle Concept 39. J. Stapleton, DSDM: Dynamic Systems Development Considered Harmful,” ACM Software Eng. Notes, Method, Addison-Wesley, 1997. Apr. 1982, pp. 29-32. 40. P. Kruchten, “Rational Development Process,” 22. E. Dijkstra, “Go To Statement Considered Harmful,” Crosstalk: J. Defense Software Eng., July 1996; Comm. ACM, Mar. 1968, pp. 147-148. www.stsc.hill.af.mil/crosstalk/frames.asp?uri=1996/07/ 23. W. Swartout and R. Balzer, “On the Inevitable Inter- rational.asp. twining of Specification and Implementation,” 41. J. McCarthy, Dynamics of Software Development, Comm. ACM, July 1982, pp. 438-440. Microsoft Press, 1995. 24. D. Tamanaha, “An Integrated Rapid Prototyping 42. K. Beck, Explained: Embrace Methodology for Command and Control Systems: Change, Addison-Wesley, 1999. Experience and Insight,” ACM Software Eng. Notes, 43. P. Coad et al., “Feature-Driven Development,” in Dec. 1982, pp. 387-396. Java Modeling in Color with UML, Prentice Hall, 25. G. Booch, Software Engineering with Ada, Benjamin- 1999. Cummings, 1983. 44. A. MacCormack, “Product-Development Practices 26. R. Budde et al., eds., Approaches to Prototyping, That Work,” MIT Sloan Management Rev., vol. 42, Springer Verlag, 1984. no. 2, 2001, pp. 75-84. 27. T. Gilb, “Evolutionary Delivery versus the ‘Waterfall 45. A. Cockburn, Agile Software Development, Addi- Model’,” ACM Software Requirements Eng. Notes, son-Wesley, 2002. July 1985. 28. B. Boehm, “A Spiral Model of Software Development and Enhancement,” Proc. Int’l Workshop Software Process and Software Environments, ACM Press, 1985; also in ACM Software Eng. Notes, Aug. 1986, pp. 22-42. 29. F. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” Proc. IFIP, IEEE CS Press, 1987, pp. 1069-1076; reprinted in Computer, Apr. 1987, pp. 10-19. 30. D. Parnas and P. Clements, “A Rational Design Process: How and Why to Fake It,” IEEE Trans. Craig Larman is chief scientist for Valtech, an Software Eng., Feb. 1986, pp. 251-257. international consulting company, and he speaks 31. W. Royce, Software Project Management, Addison- and consults worldwide. He is also the author of Wesley, 1998. Agile and Iterative Development: A Manager’s 32. W. Curtis et al., “On Building Software Process Mod- Guide (Addison-Wesley, 2003), which examines els under the Lamppost,” Proc. Int’l Conf. Software both historical and other forms of evidence demon- Eng., IEEE CS Press, 1987, pp. 96-103. strating the advantages of iterative methods. Lar- 33. H. Mills et al., “Cleanroom Software Engineering,” man is a member of the ACM and the IEEE. IEEE Software, Sept. 1987, pp. 19-25. Contact him at [email protected]. 34. S. Jarzombek, Proc. Joint Aerospace Weapons Sys- tems Support, Sensors and Simulation Symp., Gov’t Printing Office Press, 1999. 35. T. Gilb, Principles of Software Engineering Manage- ment, Addison Wesley Longman, 1989. 36. G.A. Newberry, “Changes from DOD-STD-2167A Victor R. Basili is a professor of to MIL-STD-498,” Crosstalk: J. Defense Software at the University of Maryland and executive direc- Eng., Apr. 1995; www.stsc.hill.af.mil/crosstalk/ tor of the Fraunhofer Center-Maryland, where he frames.asp?uri=1995/04/Changes.asp. works on measuring, evaluating, and improving 37. H. Takeuchi and I. Nonaka, “The New New Product the software development process and product. He Development Game,” Harvard Business Rev., Jan. is an IEEE and ACM fellow and co-editor-in-chief 1986, pp. 137-146. of Kluwer’s Empirical Software Engineering: An 38. M. Beedle et al., “SCRUM: An Extension Pattern International Journal. Contact him at basili@cs. Language for Hyperproductive Software Develop- umd.edu.

56 Computer