By the late 1960s, hardware was racing ahead of the software meant to run on it. Machines kept getting more powerful, and the programs they needed kept getting larger and more tangled, faster than anyone knew how to write them well. Projects ran over budget and behind schedule and shipped late and unreliable. The gap between what computers could do and what their software could be trusted to do had become its own emergency, and in 1968 NATO called a meeting to confront it.

The idea

Software engineering as a discipline: treat the construction of software as engineering, with process, estimation, and accountability, rather than as individual craft.

The software crisis

The problem got a name at that meeting. The term software crisis was coined by attendees at the first NATO Software Engineering Conference, held at Garmisch, Germany, in 1968. It captured a specific difficulty: writing useful, efficient, reliable programs in the time available, as the power of computers and the complexity of the problems they were aimed at both rose. The symptoms were concrete, including projects running over budget and over schedule and software that was low in quality and did not meet its requirements.

Naming the cure

The conferences, Garmisch in 1968 and Rome in 1969, did more than diagnose. They framed the response as treating the construction of software as an engineering discipline, with process, estimation, and accountability, rather than as an individual craft. The meetings played a major role in gaining general acceptance for the term software engineering itself.

Why it mattered

This is the hinge where programming began to be treated as engineering. Once the field accepted that software needed disciplined process rather than talent alone, the practices that followed, including structured testing, deliberate architecture, and documented design patterns, all became things one could study and demand. The rest of this cluster’s software notes sit downstream of that shift.

Sources