The Criminology of Code, Part 2: Prevention & Profiling

InvestigationInvestigation reconstructs what already went wrong; criminology's other half asks what makes wrongdoing more or less likely in the first place, and what environmental design does to that likelihood before anyone has to be caught. This lecture turns from forensics to prevention: reading architectural decay through the same lens criminologists use for neighbourhood decay, treating recurring developer mistakes as profileable patterns rather than random bad luck, and asking what it would mean to design a codebase where the wrong action is simply harder to take than the right one.

Broken Windows Theory of Codebases

WilsonWilson and Kelling's 1982 "Broken Windows" essay argued that visible, untended signs of disorder — a broken window left unrepaired, litter left uncleared — signal that nobody is watching or cares, which measurably increases the rate of further, more serious disorder in that environment [1]. Hunt and Thomas's The Pragmatic Programmer imported the theory into software engineering directly and explicitly: a codebase with visible small defects left unfixed — a build warning nobody clears, a TODO nobody resolves, an inconsistency in naming nobody corrects — signals to every subsequent contributor that the standard here is "sloppy is acceptable", and each new contributor calibrates their own care to match [2]. The mechanism is social, not technical: nobody individually decided to lower the bar, but the accumulated visible evidence of low care lowers it anyway, for everyone who arrives afterward.

Technical debt is the balance-sheet version of the same phenomenon. Ward Cunningham's original metaphor — from the 1992 experience report that coined the term — was explicit about the analogy being financial rather than moral: a shortcut is a loan, it is not automatically bad to take one, but it accrues interest, and the interest is paid in the reduced speed and increased risk of every future change made near it [3]. Kruchten, Nord and Ozkaya's later synthesis of the metaphor into a working theory distinguishes debt that is deliberate and tracked (which behaves like the loan it claims to be) from debt that is inadvertent or unacknowledged (which behaves much more like Wilson and Kelling's broken window — a standard silently lowered rather than a decision consciously made) [4].

Developer Profiling & Anti-Pattern Analysis

CriminalCriminal profiling works from the premise that certain classes of offence correlate with certain, recognisable behavioural patterns. The software equivalent is cognitive-bias profiling: certain classes of defect correlate strongly with certain, well-studied reasoning shortcuts, and recognising the shortcut in progress is often faster than debugging its output after the fact. Mohanani and colleagues' systematic mapping study of cognitive biases in software engineering catalogued the empirical literature and found consistent evidence for several biases recurring across requirements, design, and coding activities: confirmation bias (favouring evidence that supports an existing design decision, and under-weighting evidence against it), anchoring (over-relying on the first estimate or the first example encountered), and overconfidence in one's own code being correct, among others [5].

Two of these are common enough in day-to-day code to name directly. Premature optimisation — restructuring code for speed before measuring whether that part of the system is actually the bottleneck — is anchoring dressed as diligence: an intuition about performance, formed early, resists later correction by profiling data because the intuition was acted on before the data existed to contradict it. Copy-paste propagation — reproducing a working pattern into a new context without re-deriving whether its assumptions still hold — is confirmation bias with a keyboard shortcut: the pattern's past success is treated as evidence for its correctness here, when the actual claim being made ("these two contexts share the same invariants") was never checked. Weinberg's early observation that programmers are reliably poor judges of their own code's correctness, because they are reasoning from the intent they had rather than the text they actually wrote, underlies both patterns and predates the formal cognitive-bias literature by decades [6].

Defensive System Design

TheThe most reliable prevention is not vigilance — vigilance degrades — it is making the wrong action structurally harder than the right one. This is the software analogue of situational crime prevention: rather than relying on the offender's judgement in the moment, change the environment so the offence requires more effort or is more likely to be caught. Shigeo Shingo's poka-yoke ("mistake-proofing") principle from manufacturing quality control is the clearest statement of the idea: design the process so that the error-prone step either cannot physically be performed incorrectly, or immediately and automatically signals that it has been [7]. A plug that only fits one way is poka-yoke; a compiler error for a type mismatch is its direct software descendant.

Design by Contract generalises the principle into an architectural discipline rather than a one-off trick: preconditions, postconditions and invariants stated at module boundaries turn "please don't call this incorrectly" from a comment nobody reads into a runtime check nobody can silently bypass [8]. Type systems, exhaustive pattern matching, and immutability-by-default are the same idea at the language level — each removes an entire category of mistake from the set of things a developer's vigilance is required to catch, by making the category unrepresentable rather than merely discouraged.

References

1. Wilson, J. Q., & Kelling, G. L. (1982). Broken windows: The police and neighborhood safety. The Atlantic Monthly, 249(3), 29–38.
2. Hunt, A., & Thomas, D. (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley.
3. Cunningham, W. (1992). The WyCash portfolio management system. OOPSLA '92 Experience Report. https://doi.org/10.1145/157710.157715
4. Kruchten, P., Nord, R. L., & Ozkaya, I. (2012). Technical debt: From metaphor to theory and practice. IEEE Software, 29(6), 18–21. https://doi.org/10.1109/MS.2012.167
5. Mohanani, R., Salman, I., Turhan, B., Rodriguez, P., & Ralph, P. (2020). Cognitive biases in software engineering: A systematic mapping study. IEEE Transactions on Software Engineering, 46(12), 1318–1339. https://doi.org/10.1109/TSE.2018.2877759
6. Weinberg, G. M. (1971). The Psychology of Computer Programming. Van Nostrand Reinhold.
7. Shingo, S. (1986). Zero Quality Control: Source Inspection and the Poka-Yoke System. Productivity Press.
8. Meyer, B. (1988). Object-Oriented Software Construction. Prentice Hall.