Early Historical Project Evidence 1

Early Historical Project Evidence^[1]

^[1] Some material is adapted from [LB03].

The usual citation style is replaced with inline citations in this section, as a goal is showing the references in context.

This section emphasizes a history of early published iterative projects; there were surely many hundreds or thousands more that applied IID in the 1960s and 1970s. IID projects from the late 1980s forward are not emphasized, as by that time they were common.

Pre-1970

Although IID in software is in the ascendancy as the "modern" approach to replace ad hoc or waterfall development, its practiced and published roots go back surprisingly far at least as far back as the late 1950s, as a contemporary alternative to the nascent waterfall model, perhaps first described as the "stagewise model" for the USA air defense SAGE project by H. D. Benington in "Production of Large Computer Programs," Proceedings of the ONR Symposium on Advanced Program Methods for Digital Computers, June 1956.

See "The Historical Accident of Waterfall Validity?"

Early roots for IID are found in the work of Walter Shewhart, the quality expert at Western Electric who proposed, in the 1930s, a series of PDSA cycles (the Shewhart Cycle or Deming Wheel) for quality improvement, an idea promoted by quality guru Edward Deming, starting in the 1940s. The application of iterative PDSA to software was explored by Zultner in "The Deming Approach to Quality Software Engineering," Quality Progress, 21(11) 1988.

A milestone 1950s project applying IID was the X-15 hypersonic jet (see W. H. Dana, "The X-15 Lessons Learned," NASA Dryden Research Facility, 1993):

A major contributor to the X-15's success over the long run was its emphasis on incremental development.

Although not a software project, the X-15 is mentioned because some personnel (and hence, incremental experience) seeded NASA's 1961 63 Project Mercury, which did apply IID in software and some of the latter project's personnel seeded the IBM Federal Systems Division (FSD), another early IID proponent.

Project Mercury was run with short half-day iterations. There was a technical review of all changes, and interestingly the Extreme Programming practice of test-first development was applied: Tests were planned and written in advance of each micro-increment, and then the code was written to pass the tests. Each mini-iteration required integration of all code and passing of tests.

The Project Mercury description came from the software engineering thought leader, Gerald M. Weinberg, who provided a window onto IID versus waterfall attitudes during this period, especially on the highly visible Project Mercury system [LB03]:

We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's Service Bureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell, indistinguishable from XP.

When much of the same team was reassembled in Washington, DC, in 1958 to develop Project Mercury, we had our own machine and the new Share Operating System, whose symbolic modification and assembly allowed us to build the system incrementally, which we did, with great success. Project Mercury was the seed bed out of which grew the IBM Federal Systems Division. Thus, that division started with a history and tradition of incremental development.

All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities.

Since the early 1960s, Weinberg has been a well-known consultant and author, is an inductee of the Computer Hall of Fame, and has written classics such as Psychology of Computer Programming and Secrets of Consulting.

1970s

Early practice of IID comes from the leadership of Mike Dyer, Bob McHenry, and Don O'Neill (and many others) during their tenure at the IBM FSD, which was responsible for building many aerospace and defense systems.

What is fascinating about the FSD story is the extent and success of IID use on large, life-critical DoD, space, and avionic systems during the 1970s.

The first major FSD documented application of IID (I could find) was in 1972. This was a major, high-visibility, life-critical system of over one million lines of code: the command and control system for the first USA Trident submarine. The project included Dyer, McHenry, and O'Neill as project manager. O'Neill conceived and planned the use of IID (later called Integration Engineering at FSD) on this project; it was a key success factor, and he was awarded an IBM Outstanding Contribution Award for it. Note the visible approval by IBM leadership for IID methods.

To underline this point: IBM FSD created the IID method Integration Engineering, and it was a well-known practice on major FSD projects in the 1970s.

The Trident project could not be late: The system had to be delivered by a certain date; otherwise, FSD faced a $100,000 per day late penalty. The project was organized in four timeboxed iterations of about six months each. There was still a significant up-front specifications effort, and the iteration length was longer than normally recommended today. Although there was some feedback-driven evolution in the requirements, the IID approach was seen also as a way to manage the complexity and risks of development. See O'Neill, "Integration Engineering Perspective," The Journal of Systems and Software, No. 3, 1983.

Also in 1972, and outside of the IBM FSD, another major project that applied IID comes from an FSD competitor: TRW.

It applied incremental development on the $100 million TRW/Army Site Defense software project for ballistic missile defense. The project began in February 1972 and developed the system in five iterations. Iteration 1 did tracking of a single object, and by iteration 5, a couple of years later, the system was complete. The iterations were not strictly timeboxed, and there was significant up-front specifications work, but they were also refined in response to each iteration's feedback. See Williams, "Managing the Development of Reliable Software," Proceedings, International Conference on Reliable Software, ACM/IEEE, April 1975.

As with IBM FSD, TRW was another early adopter of IID practices. Indeed, Barry Boehm, the originator of the famous IID "spiral model" in the mid-1980s, served at TRW as Chief Scientist. Another key TRW employee relevant to this story was Winston Royce, author of the most frequently cited original paper on the waterfall. As will be explored later in "The Historical Accident of Waterfall Validity?" section on page 102, his message was misunderstood, and he was in fact a proponent of IID rather than the sequential waterfall, as it has come to be known.

Another early (mid-1970s), successful, and large application of IID at FSD was the USA Navy helicopter-ship system LAMPS. A four-year 200 person-year effort involving millions of lines of code, it was evolutionarily delivered in 45 timeboxed iterations (one month per iteration). This is the earliest project example I found where the length of iteration was in the range commonly recommended by today's IID methods. The project was quite successful. To quote,

Every one of those deliveries was on time and under budget.

It is described by the noted 1970s thought leader Harlan Mills in "Principles of Software Engineering," IBM Systems Journal, Vol 19(4), 1980.

Although unknown to most software professionals, another early and strikingly impressive example of an IID success is the heart of the NASA Space Shuttle software itself: the Primary Avionics Software System. This was built by FSD from 1977 to 1980, applying IID in a series of 17 iterations over 31 months, averaging around 8 weeks per iteration (see Madden and Rone, "Design, Development, Integration: Space Shuttle Flight Software System," Communications of the ACM, Sept. 1984). Their motivation for IID?

[The waterfall lifecycle was not suitable because] the requirements on the Shuttle program evolved during the software development process.

(How unique). Ironically in hindsight of the research evidence the authors sound almost apologetic in having to forego the "ideal" waterfall for an IID approach,

Due to the size, complexity, and evolutionary [changing requirements] nature of the program, it was recognized early that the ideal software development lifecycle (the waterfall model) could not be strictly applied. … However, an implementation approach (based on small incremental releases) was devised for STS-1 which met the objectives by applying the ideal cycle to small elements of the overall software package on an iterative basis.

This Shuttle project exhibited classic IID practices: timeboxed iterations in the eight-week range, feedback-driven refinement of specifications, and so forth.

The IBM IID method Integration Engineering was so successful that it was incorporated into the FSD Software Engineering Practices (SEP) in 1977 and disseminated to the 2,500 FSD software engineers (see O'Neill, "The Management of Software Engineering," IBM Systems Journal, 19(4), 1980). The idea of IID stimulated substantial interest within IBM's commercial divisions, senior customer ranks, and among competitors, and presentations by SEP representatives on the value of IID, rather than the waterfall to visitors was not uncommon during this period.

Another early story and paper often cited on the subject of iterative development is "A Successful Software Development," by Wong, in IEEE Transactions on Software Engineering, No. 3, 1984. It describes an air defense system project that ran from 1977 to 1980 that combined significant up-front specifications followed by iterative development. The project was ostensibly meant to fit within DoD single-pass waterfall standards, with testing and integration in the last phase. However, Wong comments on the unrealism of this approach, and their need for and advantages using IID:

The [waterfall] model was adopted because software development was guided by DoD standards. … In reality, software development is a complex, continuous, iterative, and repetitive process. The [waterfall model] does not reflect this complexity.

1980s and Later

The earliest 1980s reference I could find to a large application successfully built via IID is the 1982 $100 million USD command and control project. See Tamanaha, "An integrated rapid prototyping methodology for command and control systems: Experience and insight," ACM SIGSOFT Software Engineering Notes, Dec. 1982.

From 1984 to 1988, Magnavox Electronic Systems built a large field artillery command and control system for the USA Army, ultimately a 1.3 million line Ada project. Under the methodology leadership of Don Firesmith, and with some consulting from Grady Booch, it ran as a successful IID project composed of five iterations. The first iteration emphasized building the core architecture. The project had twice the productivity and three times the usual quality measures compared to other Magnavox projects [Firesmith87].

Dozens or hundreds more large IID projects in the 1980s can be discovered, but I'll close this brief early history of IID for large, risky projects with two related case studies started in the mid-1980s: the attempted next-generation USA and Canadian air traffic control (ATC) systems.

The attempted USA ATC project started in 1983 and ran as a classic and massive big-bang waterfall project: It was a herculean attempt to define the requirements before programming, a consequential lack of stakeholder feedback, analysis paralysis, complexity overload, and so on. The conclusion: In 1994 the government cancelled the project after having spent $2.6 billion USD, with nothing to show for it [GAO98]. The project was restarted in the late 1990s with an IID approach. To quote:

[in the new approach] FAA and the aviation community agreed to (1) use an incremental approach to modernizing the National Airspace System, referred to as the "build a little, test a little" approach; … These practices differ from those of the past in which FAA tried to deploy large, complex projects all at once, known as the "big bang" approach. [GAO99]

Similarly, in 1989, a new Canadian ATC project CAATS was started as a waterfall project, following guidance from the USA DoD waterfall-promoting standard 2167A. In 1992, after several hundred million dollars spent, requirements paralysis, and little progress deemed valuable, the Canadian government was considering cancelling the project. But, rather than abandon the effort, the project was restarted under the process leadership of Philippe Kruchten, an IID-experienced architect (and later, chief architect of the Rational Unified Process). Kruchten ran it as an iterative project, averaging six-months per iteration with a staff of several hundred, and CAATS re-surfaced as a successfully evolving system with early visible progress, ultimately with over one million lines of source code, mostly Ada. See Kruchten et al., "Modernizing ATC through Modern Software Methods," 1993 Proceedings of the Air Traffic Control Association.

2167A, unsuccessful, has since been replaced.

By the 1990s, IID use was relatively widespread, probably in the tens of thousands of projects worldwide, though varying adoption trends in different domains and cultures could be seen. Predictably, company and national cultures that emphasized hierarchical management and control, and detailed predictive planning, were the slowest adopters.