Software Engineering as Practical Anthropology

AA specification document is a fossil: it records what a domain expert managed to say out loud, on a particular day, to a particular analyst, using whatever vocabulary the two of them shared at the time. It is almost never a complete account of the work it describes. The oldest and most reliable fix for this is not a better template — it is to stop treating requirements-gathering as a transcription exercise and start treating it as fieldwork. This lecture borrows its method from anthropology: go where the work happens, watch it happen, and write down what the people doing it never thought to mention.

Participant Observation

AnthropologistsAnthropologists distinguish between what informants say they do and what they can be observed actually doing, and the gap between the two is usually where the interesting material lives. Lucy Suchman's Plans and Situated Actions made the equivalent case for systems design: formal plans are a resource people refer to when acting, not a program their bodies execute, and a system built to enforce the plan literally will fight the very improvisation that makes the plan work at all [1]. In software terms, the interview transcript gives you the plan; the workflow tells you what the plan is actually for.

This is why ethnographically-informed methods entered software engineering directly, not as a metaphor. Sommerville and colleagues' work on air traffic control rooms showed that the operators' apparently ad-hoc paper-shuffling was doing real coordination work that no formal procedure described — and that automating the visible procedure while ignoring the informal choreography around it would have broken the room [2]. Contextual Design, an influential requirements methodology, builds this observation into its first step: analysts do "contextual inquiry" — watching and questioning users in their own workplace, mid-task — precisely because interview recall reliably omits the steps people no longer consciously notice themselves performing [3].

Uncovering Tacit Knowledge

MichaelMichael Polanyi's phrase for this gap is tacit knowledge: "we know more than we can tell" [4]. A claims handler who has processed ten thousand insurance forms has internalised a hundred small heuristics — which fields to double-check when the postcode looks wrong, which combinations of answers usually mean the applicant misunderstood a question — that never made it into any procedure manual, because nobody ever had to teach them explicitly; they were absorbed on the job. Requirements-elicitation research treats this as a structural problem rather than a failure of individual honesty: Goguen and Linde's survey of elicitation techniques found that structured interviews systematically under-report exactly this class of knowledge, because it is procedural and situational rather than declarative — people are good at reporting facts and poor at reporting reflexes [5].

The practical consequence for a domain model is that the workarounds are not noise to be designed away — they are usually load-bearing. A field that gets "corrected" by three different people before it reaches the database is not evidence of a broken process; it may be evidence of a validation step nobody wrote down. Removing it without understanding why it existed is how digitisation projects quietly reintroduce the errors the paper process had learned to catch.

Translating Mental Models

OnceOnce the tacit rules are visible, the harder job starts: turning a high-dimensional, exception-riddled human workflow into a domain model that a type system and a database schema can actually represent. This is the classic move of Domain-Driven Design — build a shared, precise "ubiquitous language" with the domain experts before writing the model, because a model built on the analyst's vocabulary rather than the domain's will drift silently out of sync with the reality it claims to describe [6]. Every "just" in a requirements conversation — "it's just an approval step", "it's just a status field" — is usually hiding a decision tree the expert has stopped noticing they run.

Checkland's Soft Systems Methodology offers a useful discipline here: separate the messy "real world" description of the situation from the "systems thinking" world of formal models, and treat the translation between them as an explicit, comparable step rather than something that happens invisibly in an analyst's head [7]. Naming that translation step is what lets a team catch the moment a convenient simplification has quietly become a false constraint.

References

1. Suchman, L. A. (1987). Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge University Press.
2. Viller, S., & Sommerville, I. (2000). Ethnographically informed analysis for software engineers. International Journal of Human-Computer Studies, 53(1), 169–196. https://doi.org/10.1006/ijhc.2000.0370
3. Beyer, H., & Holtzblatt, K. (1998). Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann.
4. Polanyi, M. (1966). The Tacit Dimension. University of Chicago Press.
5. Goguen, J. A., & Linde, C. (1993). Techniques for requirements elicitation. Proceedings of the IEEE International Symposium on Requirements Engineering, 152–164. https://doi.org/10.1109/ISRE.1993.324822
6. Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley.
7. Checkland, P. (1981). Systems Thinking, Systems Practice. John Wiley & Sons.