Four Traditions Revisited
Tedre and Sutinen’s paper “Three Traditions of Computing: What Educators Should Know” has shaped my thinking ever since I first read it. And this table (reproduced from the paper) summarizes their analysis:
| Mathematical tradition | Engineering tradition | Scientific tradition | |
|---|---|---|---|
| Assumptions | Programs (algorithms) are abstract objects, they are correct or incorrect, as well as more or less efficient – knowledge is a priori | Programs (processes) affect the world, they are more or less effective and reliable – knowledge is a posteriori | Programs can model information processes, models are more or less accurate – knowledge is a posteriori |
| Aims | Coherent theoretical structures and systems | Investigating and explaining phenomena, solving problems | Constructing useful, efficient, and reliable systems; solving problems |
| Strengths | Rigorous, results are certain, utilized in other traditions | Combines deduction and induction, cumulative | Able to work under great uncertainty, flexible, progress is tangible |
| Weaknesses | Incommensurability of results, uncertainty about what counts as proper science | Limited to axiomatic systems | Rarely follows rigid, preordained procedures; poor generalizability |
| Methods | Empirical, inductive, and deductive | Analytic, deductive (and inductive) | Empirical, constructive |
As I wrote three years ago, I’m struck now by what’s not there. I think there should be a fourth column titled “Humanist tradition” that focuses on values, on how computing is used, and on how cognitive and social psychology support, shape, and limit what we can build and how we build it.
I also now think that their distinction between the engineering and scientific traditions isn’t particularly useful. In practice, they are nearly-identical attempts to turn software development into an engineering discipline on par with chemical or electrical engineering. UML, requirements engineering, the use of statistical models to predict bug rates: all are signs of “engineering envy”, and by and large, practitioners have voted with their feet and not adopted them.
Instead, the overwhelming majority of the programmers I’ve worked with fall into what I used to call a “craft” tradition, but which I now think has a lot more in common with industrial design. Using Tedre and Sutinen’s categories:
-
Assumptions: Programs are built by people who learn design and construction from examples.
-
Aims: Answer the questions, “Does it do what it’s supposed to?” and “Does its design facilitate its construction and maintenance?”
-
Strengths: Matches most practitioners’ mental model of their work.
-
Weaknesses: Lacks a rigorous foundation. (Discussions of software design are intellectually shallow compared to discussions of the design of bicycles and teapots.)
-
Methods: Mentoring.
I think this analysis explains why practitioners and software engineering researchers mostly talk past one another. Most researchers subscribe to what Scott’s book Seeing Like a State labelled “high modernism”: they believe comprehensibility and control will come from uniformity and formalism. Practitioners, on the other hand, are defending the local traditions in which they are personally invested. In my idle moments, I wonder where we’d be if that long-ago NATO conference had adopted industrial design as a metaphor instead of engineering.