The Fourth Tradition
Tedre and Sutinen’s paper “Three Traditions of Computing: What Educators Should Know” (2008) has shaped my view of computer science, software engineering, and programming since I first read it. (Its paywalled home is here, but remember, Sci-Hub is your friend…) Their analysis is worth re-reading at least a couple of times, but this table (reproduced from the paper) is an excellent overview:
| 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 |
Reading it again today, though, I’m struck by what’s not there (and by the fact that it’s taken me almost 15 years to notice its absence). 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. As a very rough draft:
-
Assumptions: Programs are built by people working in particular social settings to serve personal and organizational needs shaped by those settings.
-
Aims: Explanations of why software is built the way it is by the people who build it.
-
Strengths: Explains which problems (and which problem solvers) are considered “valid”.
-
Weaknesses: Poor generalizability; often viewed as “story telling” by people unfamiliar with social science methods.
-
Methods: Empirical and qualitative.
I’d be very grateful for feedback and improvements.