Unprecedented scope combined with the assumption that adding more programmers would accelerate delivery. No existing methodology for managing software projects of this scale. The system's own complexity exceeded the team's ability to understand it.
Fred Brooks wrote 'The Mythical Man-Month' (1975) based on the experience. The phrase 'Brooks' Law' — adding manpower to a late software project makes it later — became a foundational principle. The project proved that software complexity does not scale linearly with effort.
The Incident
In 1964, IBM announced the System/360 — a family of compatible mainframe computers. The hardware was revolutionary. The software — OS/360 — was to be the operating system that unified the entire product line. It would be the most ambitious software project ever attempted: a single operating system supporting multiple hardware configurations, batch processing, timesharing, and a comprehensive set of system utilities.
The project was estimated at 1,000 person-years of effort. It consumed 5,000. Delivery dates slipped by years. When OS/360 finally shipped, it contained thousands of known bugs. One module had so many patches that the original code was no longer visible underneath them.
The Root Cause
OS/360 failed for reasons that would become the textbook definition of software project failure:
Complexity compounded faster than understanding. The system had to support multiple memory sizes, multiple I/O configurations, and multiple processing modes. Each combination created interaction effects that multiplied the testing surface exponentially. The team could build individual components. They could not predict how those components would interact.
Adding programmers made it worse. When the project fell behind schedule, IBM added more programmers. The new programmers had to be trained by the existing team, pulling them away from development. Communication overhead grew quadratically — 10 people need 45 communication channels; 100 people need 4,950. The project got later, not faster.
The codebase became incomprehensible. OS/360 was written primarily in assembly language with pervasive use of GOTO. There were no structured programming constructs, no modular boundaries, no information hiding. Every component could reach into every other component's memory. A change to the scheduler could break the file system because both accessed shared data structures without encapsulation.
No one had done this before. There was no methodology for managing a multi-thousand-person software project. There were no version control systems, no automated testing frameworks, no continuous integration. The tools for managing software complexity did not exist because no one had needed them at this scale before.
The Pattern
OS/360 is the canonical example of complexity accretion at industrial scale. Every individual decision was locally rational — support this hardware configuration, add this feature, fix this bug with a patch. But each decision added complexity that interacted with every other decision. The system became a tar pit: every step forward pulled the team deeper.
Brooks' insight was that software projects have a fundamentally different cost structure than physical construction projects. Adding laborers to a construction site speeds up the work (up to a point). Adding programmers to a software project increases coordination costs, training costs, and communication costs. Beyond a critical size, more people means less progress.
The Aftermath
Fred Brooks, the project manager for OS/360, spent a decade reflecting on what went wrong. In 1975, he published The Mythical Man-Month, which distilled the lessons into principles that remain true sixty years later:
- Brooks' Law: "Adding manpower to a late software project makes it later."
- The Second System Effect: The second system a team builds is always over-engineered because they try to include everything they left out of the first.
- No Silver Bullet: There is no single technique that will produce an order-of-magnitude improvement in software productivity.
- Conceptual Integrity: A system designed by one mind (or a small group) will be more coherent than one designed by committee.
OS/360 was not a failure of talent — IBM employed some of the best programmers in the world. It was a failure of the assumption that talent scales linearly. It does not. Complexity scales faster than any team can grow to contain it.
The NATO Software Engineering Conference (1968), organized partly in response to projects like OS/360, coined the term "software crisis" — the observation that the industry's ability to write software had exceeded its ability to manage software. That crisis, in a meaningful sense, has never ended.