The Software Crisis: How a 1968 Conference Named Computing's Permanent Problem
Zusammenfassung
In the 1960s, hardware kept getting faster and cheaper while the software meant to run on it kept arriving late, over budget, and full of bugs — when it arrived at all. The gap became so alarming that in 1968 NATO convened a conference of the field’s leading minds in a Bavarian ski resort to confront it. They gave the problem a name — the software crisis — and proposed a cure: treat the building of software as an engineering discipline, software engineering. More than half a century later, projects still run late and budgets still blow, which is the deepest lesson of the crisis: it was never fully solved, only managed. This article tells how the discipline of software engineering was born out of an admission of failure.
The Gap That Opened in the 1960s
The first commercial computers were programmed by small teams writing small programs. But through the 1960s, machines grew vastly more capable, and the ambitions for what software should do grew with them — airline reservation systems, operating systems running many programs at once, command-and-control systems. Programs ballooned from thousands of lines to millions.
The methods did not scale. Programming was still treated as a craft practiced by individuals, with little shared method, almost no tooling, and management techniques borrowed from manufacturing that did not fit. The symptoms were everywhere: projects chronically late and over budget, software that was unreliable or never shipped at all, and code that no one could maintain. Hardware cost was falling fast while software cost rose to dominate the total — and yet software was the part nobody knew how to control.
Garmisch 1968: Naming the Crisis
The idea for a reckoning came from the German computer scientist Friedrich (Fritz) Bauer. In October 1968, the NATO Science Committee convened the first NATO Software Engineering Conference in Garmisch-Partenkirchen, Germany. The roughly fifty attendees were a who’s-who of the young field, including Edsger Dijkstra, Tony Hoare, Alan Perlis, Peter Naur, and Niklaus Wirth.
What made Garmisch historic was its candor. Rather than presenting polished successes, participants openly admitted that the field was in trouble — that a “software crisis” was raging. The conference report, edited by Peter Naur and Brian Randell, captured engineers confessing to disasters in a way the profession rarely had before. The very title of the conference contained the proposed solution: the phrase “software engineering” was chosen deliberately and provocatively, to assert that software should be built with the rigor, discipline, and predictability of an engineering profession — an aspiration, not yet a reality.
A second conference followed in Rome in 1969, but it was less harmonious; the optimism of Garmisch gave way to disputes about what the new discipline even was. Still, the term had stuck, and an entire field organized itself around it.
Diagnoses and Proposed Cures
Naming the crisis launched decades of attempts to cure it. Several landmark ideas trace directly to this period:
- Structured programming. Dijkstra’s 1968 letter “Go To Statement Considered Harmful” and the broader structured-programming movement argued that disciplined control flow made programs possible to reason about — a first serious attempt to make code intellectually manageable. See Edsger Dijkstra and Structured Programming.
- The Mythical Man-Month. In 1975, Frederick Brooks distilled the painful lessons of managing IBM’s vast OS/360 software project into a book of essays. Its most famous claim — Brooks’s Law — is that adding manpower to a late software project makes it later, because communication overhead grows faster than output. He argued that conceptual integrity is the most important property of a system and is best achieved by few minds, not many.
- No Silver Bullet. In 1986, Brooks followed up with the essay “No Silver Bullet,” arguing that there is no single development, in either technology or management technique, that promises even a tenfold improvement in productivity within a decade. He split software difficulty into the essential (the inherent complexity of the problem) and the accidental (the friction of our tools), and warned that we had already eliminated most of the accidental kind — so no magic remained.
Later decades layered on more responses: high-level languages, software process models, the Capability Maturity Model from the Software Engineering Institute, object orientation, design patterns, and eventually the Agile and DevOps movements — each in part a reaction to the same chronic failure to deliver software on time and working.
⚠️ Dead End: The Cure That Never Fully Worked
The hopeful premise of 1968 was that software could be made as predictable as bridge-building if only it were treated as proper engineering. In its strongest form, that promise was a dead end. Decades of method, process, and tooling improved matters enormously — but large software projects still run late, blow budgets, and fail. Industry surveys have for years reported that a large share of big software projects are challenged or cancelled outright, and spectacular failures continued long after Garmisch (see Famous Software Disasters).
Brooks had already explained why in No Silver Bullet: the hard part of software is essential complexity — the difficulty of precisely specifying and managing inherently complex behavior — and no process change makes that essential difficulty disappear. The “crisis,” in other words, was misnamed. A crisis is an acute, temporary emergency; this was a permanent condition of the medium. The mature view that emerged is that software engineering is not the elimination of the crisis but the ongoing, disciplined management of it: estimation, testing, version control, review, and incremental delivery are tools for living with essential complexity, not for abolishing it.
Legacy
The 1968 conference is the conventional birthdate of software engineering as a named discipline, and its honesty set a useful tone: the field began by admitting it did not know how to do its job reliably. Everything afterward — structured programming, project-management theory, testing as a discipline, agile methods, the modern emphasis on small teams and conceptual integrity — can be read as a long, unfinished answer to the question raised at Garmisch. The software crisis was never declared over because, in Brooks’s sense, it cannot be. Naming it was the achievement; the work of managing it never ends.