"These aren't actions; they are aspirations. Why are these aspirations? The engineers who wrote the buggy code weren't trying to write buggy code. They were responding rationally to the system as it existed (with time pressures, available information, review processes in place and the tooling they had available and so on). If you don't change the system, you're just asking people to be better at resisting it. And that simply doesn't work. POSIWID!"
"Every post-mortem action should pass this test: If someone ignores the action, what mechanism prevents the bug from recurring? If the answer is "nothing", then it's not an action, it's just a tick-box on a postmortem review that'll achieve nothing. To give some examples: "Ensure all code is tested before merge" - This is an aspirational commitment. Nothing in the system has changed, other than a vague promise. The systemic alternative might be to introduce a coverage ratchet."
Failures commonly result from systemic incentives and constraints rather than individual malice or carelessness. Engineers often act rationally given time pressure, information, review processes, and tooling. Effective remediation requires changing the system so that ignoring the action still prevents recurrence. Actionable changes include enforceable mechanisms such as coverage ratchets, CODEOWNERS files, and lightweight ADRs instead of vague promises. Every remedial action should be evaluated by asking whether noncompliance still blocks the failure from recurring; if not, the action is merely aspirational and will not reliably reduce future risk.
Read at Substack
Unable to calculate read time
Collection
[
|
...
]