A short history of software projects. Why the big ones run late

Why this history matters

If you run a company and someone pitches you a software project, you are betting on something with a famously bad record. That's not a sales line. It's what fifty years of research on software projects found, again and again. The good news is that the same research explains why, and what works better. This is a short tour of the six ideas that shaped how software gets built today, in the order they arrived.

1975: Fred Brooks and the mythical man-month

At IBM, Fred Brooks managed the development of OS/360, the operating system for the company's System/360 computers. In 1975 he wrote up what he learned in a book of essays, The Mythical Man-Month (Addison-Wesley). Its best-known line is now called Brooks's law:

"Adding manpower to a late software project makes it later." (Fred Brooks, 1975)

The title names the mistake. A "man-month" treats people and months as if they can be swapped: if one person needs ten months, ten people should need one. Brooks argued that this only works for tasks that can be split up with no talking between the people doing them. Software isn't like that. Three reasons are usually given:

1. Ramp-up. New people aren't productive on day one, and the people who train them stop doing their own work to do it.
2. Communication. Every new person adds new conversations. The number of pairs in a group grows much faster than the group: 5 people have 10 possible pairs, 10 people have 45, and 15 people have 105. (Brooks's formula is n(n − 1)/2. At 50 people it's 1,225.)
3. Some work can't be split. Brooks's own example: nine women can't make a baby in one month.

Brooks himself called the law an "outrageous oversimplification," and later writers have pointed out the limits. It applies to projects that are already late. Adding people early, or adding someone who already knows the system, can help. But the core point has held up: past a certain size, more people mostly means more coordination, not more progress.

1981: Barry Boehm and the cost of size

Brooks wrote from experience. Barry Boehm went after the same problem with data. His 1981 book Software Engineering Economics (Prentice-Hall) introduced COCOMO, a model that estimates the effort a project will take from its size, fitted to records of real projects.

The important detail is one number in the formula: the exponent on size. In COCOMO, effort grows with size raised to a power above 1, from 1.05 for small, familiar projects up to 1.20 for large, tightly constrained ones. A power above 1 means a project twice as big takes more than twice the effort. Economists call this a diseconomy of scale. Building in a factory gets cheaper per unit as volume grows. In Boehm's data, building software got more expensive per unit as projects grew, for the same reasons Brooks gave: more people, more coordination, more chances for pieces not to fit.

Boehm's second big contribution came in 1986 and 1988 with the spiral model. It was a reply to the "waterfall" way of working, where a project moves once through requirements, design, building and testing, and nobody sees working software until the end. Boehm proposed going around in loops instead. Each loop starts by asking what is most likely to go wrong, builds just enough (often a prototype) to find out, and lets the customer review it before the next loop. Risk gets handled early, while it's still cheap to change course.

1986: Takeuchi and Nonaka's rugby team

The same year Boehm first published the spiral model, two professors at Hitotsubashi University in Japan, Hirotaka Takeuchi and Ikujiro Nonaka, published "The New New Product Development Game" in the January–February 1986 Harvard Business Review. They weren't writing about software. They studied how companies including Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox and Hewlett-Packard developed new products quickly.

They described two ways of working. In the old way, the project "moved like a relay race," with one group of specialists "passing the baton to the next group": marketing, then research, then engineering, then production. In the new way, "as in rugby, the ball gets passed within the team as it moves as a unit up the field." One team, made of people from every function, works together from start to finish, and the phases overlap instead of waiting on each other.

They listed six traits of these teams: built-in instability (a hard goal with freedom on how to reach it), self-organizing project teams, overlapping development phases, "multilearning," subtle control, and organizational transfer of learning. Their example from Fuji-Xerox: the FX-3500 copier team cut development time from 38 months for an earlier model to 29 months.

One section of the article is titled "Moving the Scrum Downfield." In the early 1990s, Ken Schwaber and Jeff Sutherland developed a way of running software teams in short cycles and named it Scrum. They first presented it together at the OOPSLA conference in 1995, according to The Scrum Guide, and Takeuchi and Nonaka's article is widely credited as its starting point. Scrum work happens in sprints, fixed cycles of one month or less, each meant to end with something usable.

1994: the CHAOS report puts numbers on it

By the 1990s, companies were spending heavily on software and many projects were failing. In 1994 the Standish Group, a research firm, published the first CHAOS report. It surveyed 365 IT executives about 8,380 software projects at U.S. companies of every size. It estimated that U.S. companies and government agencies were spending about $250 billion a year on software development. The headline numbers:

According to the report, the challenged and cancelled projects cost on average 189% of their original estimates and took 222% of their original time estimates. On average they delivered only 61% of the features first specified.

Size mattered, just as Brooks and Boehm predicted. At large companies (over $500 million in revenue a year), only 9% of projects succeeded, and finished projects delivered about 42% of the features first planned. Medium companies succeeded 16.2% of the time and small companies 28%. For 1995, the report estimated $81 billion would be spent on software projects that were cancelled and another $59 billion on overruns. It pointed to the new Denver airport, where the failure to deliver working software to handle baggage was costing the city $1.1 million a day.

The report also asked what successful projects had in common. The top factors were user involvement (15.9% of answers) and executive management support (13.9%). Further down the list was "smaller project milestones": breaking the work into smaller pieces.

2001: the Agile Manifesto

In February 2001, seventeen software developers met at the Snowbird ski resort in Utah, among them Ken Schwaber and Jeff Sutherland. They signed a short statement called the Manifesto for Agile Software Development. It pulled the lessons of the previous 25 years into four lines:

It ends: "That is, while there is value in the items on the right, we value the items on the left more." Each line answers something earlier in this story. Small teams that talk to each other, not bigger teams with more process (Brooks). Software you can use early, so you find problems while they're cheap (Boehm's spiral). The customer working with the team throughout (Takeuchi and Nonaka, and the CHAOS report's top success factor). And a plan that changes when you learn something, instead of a fixed plan that delivers 61% of what was promised.

2006: Stephen M.R. Covey and the speed of trust

The last idea comes from outside software. In 2006, Stephen M.R. Covey, with Rebecca R. Merrill, published The Speed of Trust: The One Thing That Changes Everything (Simon & Schuster). His argument is that trust is not a soft extra. It is an economic factor you can see in time and money. As the publisher-authorized summary puts it, "when trust goes down, speed goes down and cost goes up," and when trust goes up, speed goes up and cost goes down. Covey calls the extra cost of low trust a "trust tax" and the payoff of high trust a "trust dividend."

One of his examples: Warren Buffett bought McLane Distribution from Wal-Mart on the basis of a two-hour meeting. Because of the high trust between the two sides, the deal took less than a month and avoided the usual months of due diligence and millions in fees for attorneys.

Covey's point explains why the Agile Manifesto's third line, customer collaboration over contract negotiation, works. A project where every change needs a renegotiated contract pays the trust tax on every step. A project where the customer and the team trust each other can change course in a conversation. It's also why the small first step matters: it's the fastest way for a customer and a builder to earn each other's trust before the bigger bets.

A fair warning about the numbers

The CHAOS report is the most quoted statistic in this story, and it has real critics. In 2006, Magne Jørgensen and Kjetil Moløkken-Østvold of Simula Research Laboratory reviewed the 1994 report. Every other survey of the same period they could find put the average cost overrun at about 30%, not 189%, and those surveys had been through scientific review. When they asked the Standish Group how projects were selected, the answer, in their words, was that sharing it "would be like giving away their business for free." They also found the number quoted two different ways, as a "189% cost overrun" and as "189% of original estimate," which is an overrun of 89%.

So treat the exact percentages with care. The direction, though, is backed by every other source here: big, long, all-at-once projects fail more often than small ones. The researchers disagree about how bad it was, not about which way it points.

Waterfall, iterative, Scrum and Kanban: what's the difference?

These four names come up whenever someone pitches a software project, and they're often used loosely. Here's what each one means.

Waterfall is the one-pass approach: write all the requirements, then design, then build, then test, then deliver. It's usually traced to Winston Royce's 1970 paper "Managing the Development of Large Software Systems." But as Craig Larman and Victor Basili point out in their 2003 history in IEEE Computer, many people incorrectly read Royce's paper as a model for single-pass waterfall. Royce actually recommended doing it twice, so that the version delivered to the customer is really the second one, and suggested a 30-month project might start with a 10-month pilot.

Iterative and incremental development builds the system in repeated cycles, each one adding a working piece the customer can review. It's older than most people think. Larman and Basili trace it to the 1950s X-15 hypersonic jet program and to NASA's early-1960s Project Mercury, which ran its software in very short, time-boxed iterations of half a day. Boehm's spiral model, above, is one form of it.

Scrum is a specific way of running iterative work. The Scrum Guide calls it "a lightweight framework." Work happens in sprints of one month or less, a team of one Product Owner, one Scrum Master and Developers runs it, and each sprint has four set meetings: Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective.

Kanban skips sprints altogether. Kanban University's Official Kanban Guide describes it as a management method, "not a methodology nor a process framework," that you apply on top of the way you already work. Its roots are in lean manufacturing, and the method was set out by David J. Anderson in his 2010 book Kanban: Successful Evolutionary Change for Your Technology Business. The core practices are to make the work visible (usually on a board), limit how much is in progress at once, manage the flow, make the rules explicit, and improve through small experiments. It prescribes no roles and no fixed cycles.

None of these is right for everything. Waterfall still fits work that is well understood and won't change. Scrum suits a dedicated team building one product. Kanban suits a steady stream of requests, which describes a lot of office work. What the history in this article argues against is the big single pass, where nobody sees working software until the end. Our own approach is iterative and incremental: one desk at a time, delivered in phases, each one in use before the next begins.

What this means for an office project today

Most of this research was done on very large projects at very large companies. A mid-size manufacturer or distributor automating its order desk is a much smaller job. But the same forces show up at any size: a big plan written before anyone sees working software, a long wait for one big launch, and the people who do the work kept out of it until the end.

What the history suggests, in plain terms:

1. Start with one process, not the whole office. A small first step keeps the team small and the coordination simple, and you find out quickly whether the approach works.
2. Get working software in front of the people who do the job, early. Real orders and real exceptions teach more than a requirements document.
3. Keep the people doing the work involved throughout. In the CHAOS survey, user involvement was the top success factor.
4. Grow in steps. Once the first piece works, add the next one on the same foundation. Each one goes faster than the last.
5. Be suspicious of a fix that adds people to a late project. Brooks's point still holds. Cut the scope instead.

This is how we work at Peekgentic: one desk first, built on a foundation the next desks reuse, with the person who does the work shaping it. See how we deliver.