A History of Quality in Software Engineering | My blog

Share via

Subscribe for a few deep articles per year

Subscribe

Thank you for sharing the article

Share via

Software quality practices have evolved over six decades. What began as a response<br>to the “software crisis” of the 1960s has grown into collaborative specification<br>techniques that bridge the gap between business and technical teams.

Contents

Evolution of Quality Approaches

The Software Crisis (1968)

Structured Programming (1968)

Fagan Inspections (1976)

Cleanroom Software Engineering (1980s)

Personal Software Process (1990s)

User Stories (1990s, XP origin)

Extreme Programming (1996-1999)

UML and Design Communication (1997)

Test-Driven Development (~2000)

Given-When-Then Format (early 2000s)

Behavior-Driven Development (2006)

Specification by Example (2010s)

The C4 Model (2011)

Example Mapping (mid-2010s)

TDD vs BDD

Common Pitfalls

Key Figures

Further Reading

Example Story: Customer Books a Cleaning Appointment

Evolution of Quality Approaches

1968-1990s: Quality through PROCESS

The early focus was on disciplined processes to catch defects: Fagan Inspections (formal peer review), Cleanroom (defect prevention), and PSP (individual measurement).

1994-1997: Quality through DESIGN COMMUNICATION

Teams needed shared visual languages. UML unified competing notations into a standard for modeling software systems.

1996-2001: Quality through PRACTICE

Extreme Programming shifted focus to lightweight practices: TDD, pair programming, and continuous integration.

2001: The Agile Manifesto

Seventeen practitioners valued “working software over comprehensive documentation,” creating tension with UML-heavy approaches. Source: Agile Manifesto

2006-2011: Quality through LIGHTWEIGHT COMMUNICATION

Bridging business and technical teams: BDD (natural language specs), C4 Model (just enough diagrams), and Specification by Example (collaborative examples).

PROCESS --------> DESIGN --------> PRACTICE --------> LIGHTWEIGHT<br>1968-1990s 1994-1997 1996-2001 2006-2011<br>| | | |<br>v v v v<br>Inspections UML XP & TDD BDD & C4<br>Cleanroom Sequence Pair prog. SbE<br>PSP diagrams CI Example Map

The Software Crisis and Birth of Software Engineering (1968)

The term “software crisis” was coined at the first NATO Software Engineering<br>Conference in Garmisch, Germany in 1968. The conference, attended by over fifty<br>experts from eleven countries including Edsger Dijkstra, Tony Hoare, and Niklaus<br>Wirth, confronted a growing problem: software projects were consistently over<br>budget, overdue, and unreliable.

As Dijkstra later observed in his 1972 Turing Award lecture:

“The major cause of the software crisis is that the machines have become<br>several orders of magnitude more powerful… as long as there were no<br>machines, programming was no problem at all; when we had a few weak<br>computers, programming became a mild problem, and now we have gigantic<br>computers, programming has become an equally gigantic problem.”

The conference deliberately adopted the provocative term “software engineering”<br>to suggest that software development needed the rigor of traditional engineering<br>disciplines. This event marked the beginning of systematic approaches to<br>software quality.

Structured Programming (1968)

That same year, Dijkstra published his famous letter “Go To Statement Considered<br>Harmful” in Communications of the ACM, marking the beginning of structured<br>programming.

Definition: A programming paradigm using block-based control flow instead of<br>arbitrary jumps via goto statements.

The Three Control Structures

Dijkstra showed that any program can be written using just three constructs:

Sequence - Statements execute one after another in order:

read_input()<br>process_data()<br>write_output()

Selection - Choose different paths based on a condition:

if user_is_authenticated:<br>show_dashboard()<br>else:<br>show_login_form()

Iteration - Repeat statements while a condition holds:

while items_remaining:<br>process_next_item()

Core principle: These three control structures are sufficient to express any<br>computable function (the structured program theorem).

Key insight: Dijkstra observed that the quality of a programmer’s code was<br>inversely proportional to the number of gotos used. Code without gotos can more<br>easily be proven correct.

By the end of the 20th century, nearly all programming languages had adopted<br>structured programming constructs. Languages that originally lacked them<br>(FORTRAN, COBOL, BASIC) added support.

Fagan Inspections (1976)

Michael Fagan at IBM developed formal software inspections as a systematic<br>method for finding defects in documents, code, and specifications.

Definition: A formal peer review process with predefined roles, entry/exit<br>criteria, and structured meetings focused solely on defect detection.

Inspection Roles

Moderator: Leads the inspection and ensures the process is followed

Reader: Presents the material being inspected to the team

Author: Created the work...