Software crisis
The software crisis was not a one-off moment but a diagnosis sustained over decades regarding the difficulty of building software systems predictably and with quality. It is the historical context that explains why process models, maturity models such as CMM-SW, and, later, agile approaches emerged.
The underlying problem
The growth in demand for software in the 1960s far outstripped the industry's capacity to deliver it reliably. Software projects showed recurring patterns of failure: systematic delays, final costs far exceeding estimates, systems that did not do what the customer needed, and software that was hard to maintain. Roger Pressman put it this way:
Effective software project management focuses on the four P's: people, product, process, and project. The manager who forgets that software engineering work is an intensely human endeavor will never have success in project management. (Pressman, 1992)2
Milestones in Software Development Knowledge (1960s and 1970s)
The period surrounding the software crisis was also one of intense intellectual activity:
- 1962: The first algorithm for binary search is published.
- 1966: Böhm and Jacopini publish the founding paper of structured programming, laying the groundwork for eliminating the GoTo statement.
- 1968: Edsger Dijkstra writes his famous letter "GoTo Statement Considered Harmful," in the midst of the debate on structured programming. That same year, the NATO conference is held.
- 1976: The first work on structured programming and the first book on requirements analysis are published.
- 1977: Tom Gilb publishes the first book on software metrics.
The response: from processes to agility
The initial reaction to the software crisis was the formalization of processes: sequential development models, maturity models, and process standards. The goal was to make development predictable through process discipline.
This response was partially effective but created its own problems: heavyweight processes, excessive documentation, and little capacity to respond to change. The tension between process rigor and adaptability was the breeding ground from which the Agile Manifesto emerged in 2001.
In a sense, agility is not a rejection of the lessons of the software crisis, but a different response to the same problem: how to deliver software that is high-quality, on time, and solves the customer's real problem.
Common mistake
Presenting the software crisis as a solved problem. The symptoms the crisis described (projects that run late, go over budget, and fail to do what the customer needs) are still common in 2025. Agility has significantly improved the situation in many contexts, but it has not eliminated the problem. For decades, the Standish Group's Chaos Report has consistently documented that a significant proportion of technology projects still fail or deliver only partial results.
References
- Bauer, F.; Bolliet, L.; Helms, H. (1968). Software Engineering. NATO Software Engineering Conference. Garmisch: Peter Naur and Brian Randell.
- Böhm, C.; Jacopini, G. (1966). "Flow diagrams, Turing machines and languages with only two formation rules". Communications of the ACM, 9(5), 366–371.
- Dijkstra, Edsger W. (1968). Go To Statement Considered Harmful.
- Pressman, Roger. (1992). Ingeniería de software: un enfoque práctico [Software Engineering: A Practitioner's Approach, in Spanish]. McGraw-Hill.
See also
Want to advance in agility? You can search for course and exam calls, or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.