Cultures of programming
An incomplete history of
getting programs to behave

Tomas Petricek, University of Kent
tomas@tomasp.net | @tomaspetricek

How did software get reliable without proof?

(Hoare, 1996)

"Twenty years ago it was reasonable to predict that the size of software would be severely limited by [its] unreliability."

"Fortunately, the problem of program correctness has turned out to be far less serious than predicted."

"So [a question arises]: why have twenty years of pessimistic predictions been falsified?"

Origins

From black art to a discipline

"Programming in the early 1950s was a black art, a private arcane matter involving a programmer, a problem, a computer, and perhaps a small library of subroutines and a primiti- ve assembly program"

(Backus, 1976)

Establishing a discipline

Hacker culture of programming

Learning through practice
Favours individual skills
Knowledge not written down

Establishing a discipline

Mathematical computer science
Programming as engineering discipline
Programming as scientific management

Mathematical culture

Programming as mathematics

Notion of algorithm becomes central

Use formal methods to show correctness

Worked well in academia!

Engineering culture

The black art of programming has to make a way for the science of software engineering.

NATO 1968 and 1969 Conferences on Software Engineering

Managerial culture

Unlocking Computer’s Profit Potential (McKinsey, 1968)

Control over budgets, complexity, scheduling and the workforce.

Focus on organisation and development proces

Debugging

Getting programs to work

Debugging Epoch Opens (1965)

Limiting factors for computing

Hardware until mid-1950s
Programming until mid-1960s
What now? Now: debugging.

Terminology in the 1960s

Program checkout
Debugging and testing
Error handling

On-line debugging (1966)

"With some care, it has been possible, for example, to find a bug while at a breakpoint in running a test case, call the [structure] editor to make a correction, run the program on a simpler test case to verify the correctness of the change, then resume execution of the original test case from the breakpoint."

Error handling

Recovering from failures

ON in PL/1 (1964)

Allow writing
robust programs

Handle 23 known errors

ERRORSET in LISP (1962)

More control to programmers

Exceptions

John B. Goodenough (1975)

Introduces "exceptions"
Language feature
Theory of exceptions

Exception as boundary object

Studied formally
Implemented in compilers
Handled in reliable ways

Exceptions in telecom

One machine is not enough

When something goes wrong, kill the process

Supervisor process restars

Exceptions as a basis for programming style

Testing

Getting programs to solve the problem

Computer Program Test Methods Symposium (1972)

Testing distinguished
from debugging

Companies hire test managers and test technicians

Test automation establishes a test as an artifact

Growth of software testing

(Gelperin & Hetzel, 1988)

Demonstration period (1957-78)

Test to show that programs
work as required
Alternative to proofs

Destruction period (1978-82)

Test to find errors
Enables new tool developments
Mutation testing, random testing

Testing as part of the development process

Testing after coding in Waterfall (1970)

Unit testing separate from acceptance tests

Extreme programming

Test-Driven Development

Programmers & customers
Write tests first
Then write code and improve

Development methodology

From black art to engineering
Engineering take on
managerial methods

Conclusions