One of my personal favourite phrases that I’ve seen in the past few years is the Retrospective Prime Directive:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

— The Retrospective Prime Directive.

It only occurred to me, while mulling over this article after the first draft, that my own context is getting in the way. I know what a retrospective is, but you, in your context, might not! A “retrospective” is a meeting that we hold at the end of each period of software development (called a ‘sprint’) where we explore the aspects which went well, and the things we could have done better. The goal of the meeting is to tweak the software development process to make things better the next time around. These meetings are about improving our software development process.

In some ways, it’s similar to a post-mortem meeting, but that’s usually tied to a catastrophic event and trying to figure out what could be done to prevent it happening again. Both meetings are about trying to improve the overall team’s process, not trying to blame, nor point out the failings of an individual.

I first saw the Retrospective Prime Directive emblazoned on the wall of a friendly local company who were hosting a hack day. But it’s taken a few years to really sink in. I now have it as a desktop wallpaper on my laptop. Paraphrased, it could be:

Given the context we understood at the time, we did what we believed to be the right thing.

There are a couple of tricky bits to this statement, and they make it all the more powerful:

• People are genuinely doing what they believe to be the right thing. They are optimising for what they believe to be the best possible outcome, as far as they understand the situation. This doesn’t necessarily mean that they did the right thing from your perspective, or even from a commonly agreed community¹ perspective. But they truly did think they were doing the right thing, given the context in which they were operating.

• You might not fully appreciate the full context in which they were operating at the time.

Those are two important notions, which I feel the need to reiterate:

• People try their best, try to do the right thing²; and

• they operate within a context (an environment) which you might not fully understand.

It’s easy to think of examples of this from the software development landscape. I have taken shortcuts when implementing a particular feature, because we’re up against a hard deadline imposed by an external stakeholder. I’ve missed out on writing the best possible tests for my code because I lacked the knowledge of the testing framework. I’ve introduced bugs into production software because I didn’t fully understand the problem domain.

In some cases (I hope!), I’ve made the right choice, because I had access to all the information I needed in order to make the best possible decision. And in the situations where I didn’t have access to that information, I hope I provided my boss with enough context (from my environment) for her to make the right decision with her more complete context.

But in some cases, in retrospect, I know I’ve made poor decisions. In the examples I can think of, I thought I was doing the right thing at the time, but it’s my context – my understanding of the world – which was at fault. I’ve taken shortcuts writing code because I thought there was time pressure that didn’t exist. I’ve introduced bugs into production software because I’ve had a massive hangover and shouldn’t have allowed myself to be anywhere near a cap deploy³.

So it’s all about context. Do you fully understand the context in which a decision was made? Do you really understand the state of the business when a particular coding choice was made? What was the individual’s mental state when they wrote that line of code – is the comment a bit snarky because they’d just had an argument with their partner, or had a sleepless night from being up with an ill kid? In an ideal world, this sort of context wouldn’t impinge on indirectly connected environments – we’d all be able to silo off all our separate contexts – but I’m afraid we’re all just human.

The trouble with context is that it’s all-encompassing. A single developer, writing a line of production code, has the entire history of the business as their context. They also have their personal lives: marriage, kids, childhood, parents, learning, everything. Who can say which perfect storm caused them to write the map implementation in a way that leaked memory (only) in the production environment? Worse still, they also have the context of all the stuff they don’t (yet) know: personally, I might have known how to write the map so it didn’t leak memory⁴, but what trade off have I made between learning that, and incorporating some other context my colleague already knows?

The trouble with context is that it can get a bit faulty, too. This is the fundamental (at least, in my context!) problem with some mental illnesses. As a human being, you have core beliefs: those things that you’ve learned from your parents at a young age, and that you know to be true. These can be positive traits, like hard work, diligence, and honour. They can also be less positive, like viewing yourself as ‘not good enough’, or ‘not important’. These core beliefs can filter all your other experiences – meaning that the context you build up is biased towards these core beliefs. When your context gets messed up like this, you can be still be trying to do what you believe to be the right thing, you’re just working on faulty information.

A popular technique in retrospectives and post-mortems is to try and figure out the root cause of a particular problem (called ‘root cause analysis’) on the basis that it makes sense to fix the root cause of a problem, rather than applying a sticking plaster to the current symptom. Toyota’s Lean Production System – from where the Lean software development movement borrows many of its ideas – has a technique called the “Five Whys,” which keeps asking “why?” (Anyone with a toddler will be all-too-familiar with this technique.) The goal is to ask deeper questions in order to understand the root cause. And the important, sometimes forgotten, key is to question the process, not the individual people involved. It’s not supposed to be a way to assign blame.

But how about we remember the retrospective prime directive? Let’s assume the first part is an invariant:

we understand and truly believe that everyone did the best job they could

The question, instead of “why”, then becomes, “what was the context in which this seemed like the right thing to do?” I wonder if that would be a more useful question?

---

It didn’t start out this way, but I suspect some of my mulling on this article came from reading John Allspaw’s The Infinite Hows, where he argues we should ask “how?” in post-mortems, instead of “why?” I guess I’m agreeing that “why?” isn’t always the most useful question to ask, and that instead we should be asking, “what was the context that made this seem like the right decision?” What do you think is the right question?

---

I’ve occasionally messed around with extreme examples of the conjecture that people are fundamentally good, and that they were doing what they believed to be the right thing, given their understanding of the world. How does that work with Margaret Thatcher, for example? Yep, despite her being vilified for her treatment of miners, and of Scotland, I think she strongly believed in what she was doing, and believed she was doing the right thing. How about Hitler (to invoke Godwin)?

I guess the point here is: understand the context in which a decision was made. What you’re looking at may seem crazy, or silly, or just plain misinformed. But the person who wrote it was doing the best they could, given the context in which they were operating. Just like you’re currently doing the best you can, given your current context (which might look crazy in retrospect, too). People are good, and they’re trying to do the right thing. That’s the key thing to remember, even when it seems unlikely.

Of course, I’m writing what I believe to be right, given my personal context. I might be wrong, which might prove I’m right. ;-)