OS/360

In the AI Story

OS/360 was not a failure in the simple sense. It shipped. It served IBM's System/360 line for years. Its descendants remain in production on mainframes around the world. But the cost of shipping it — in dollars, in schedule, in the personal toll on the people who built it — was far greater than anyone anticipated, and the lessons Brooks extracted from the experience were lessons about the nature of software development itself, not about the specific circumstances of this specific project.

The project taught Brooks that adding programmers to a late project does not rescue the schedule; it worsens it. This observation became Brooks's Law. It taught him that the second system — the ambitious follow-up to a successful first system — is especially dangerous, because the architect imports confidence without importing the constraints that disciplined the first. It taught him that conceptual integrity is the most important property a system can possess, and that it cannot be achieved by committees. It taught him, perhaps most durably, that the hard part of software is thinking clearly about what the software should do, and that no amount of implementation effort compensates for specification failure.

OS/360 also demonstrated what Brooks later formalized as the tar pit: the accumulation of essential complexity over the life of a project, an accumulation that is invisible until it is too late. The project did not sink because of a single catastrophic decision. It sank because of the steady accretion of decisions that were individually reasonable and collectively fatal.

The AI transition returns to OS/360's lessons in a sharpened form. The patterns Brooks identified were properties of large-team software development under conditions of high communication overhead. Those conditions are now optional rather than mandatory. The builder who can avoid them — by working alone with AI, by preserving conceptual integrity through single-mind design, by iterating rapidly rather than committing to monolithic specifications — can escape the specific pathologies that sank OS/360. What she cannot escape is the essential complexity Brooks discovered underneath them, which OS/360 made visible and which the current moment has made inescapable.

Origin

IBM announced the System/360 family in April 1964. The OS/360 operating system was intended to ship in 1965 but slipped repeatedly, with multiple versions released over the following years. The project at its peak employed over a thousand people and consumed over five thousand person-years of effort. Brooks managed the project through its most difficult period and left IBM in 1965 to found the computer science department at the University of North Carolina at Chapel Hill.

Key Ideas

OS/360 was the empirical source of Brooks's framework. Nearly every principle in The Mythical Man-Month can be traced to a specific pattern Brooks observed in the project.

The project shipped. It was painful, it was late, it was over budget — and it worked. The lessons are about the cost of success, not about the cost of failure.

Adding programmers to the late schedule made things worse. The empirical foundation of Brooks's Law.

The second-system effect was visible. OS/360 was a second system, and it exhibited the bloat and ambition that Brooks warned would follow early success.

Conceptual integrity was lost and could not be recovered. Multiple teams produced interfaces that reflected different assumptions, and no amount of subsequent reorganization restored the coherence.