A room full of right answers, and we were all wrong

A few years ago I read a story of a software consultant raising concerns about software a defence company owned. He finds memory leaks all through it, flags them to the company, and gets a four-word reply: “Of course it leaks.”

No alarm. No fix on the way. The company was completely comfortable with a bug that in most systems would be a serious problem.

Although I’ve never experienced a scenario exactly like this myself, there are parallels with something I recently experienced. I walked in with about as little context as that bug report carried, and the reaction threw me the same way.

We were building an ACL (Anti-Corruption Layer) around an external system, a translation seam to keep their model from leaking into ours, and I needed sign-off from a group of non-technical stakeholders. The decision was small and specific: do we agree on this contract, the shape of what crosses the line. I walked in with the proposal and started talking through it.

It went sideways inside ten minutes. People had opinions about the external system the calls were coming from. People had opinions about our internal system the calls were going into. Someone raised an edge case in a workflow that had nothing to do with what we were deciding. None of it was wrong. None of it was the question. I left with no decision and a polite list of things to “look into.”

The mistake was obvious afterwards. I’d given them the decision but not the context that made it decidable. Without it, every detail in the room carried the same weight, so people reached for whatever was in front of them. They had no way of knowing which things sat inside what we were deciding and which were just noise.

Which brings me back to the original consultant, and the original company, and why there were no alarm bells ringing.

The memory leaks weren’t a concern for the defence company. Why? Because the team had measured how fast the software lost memory, taken the longest the program could ever run, doubled it to be safe, and fitted the hardware with that much RAM. And here’s why it really didn’t matter: the software ran on a missile. When the missile arrives at its destination, it explodes, along with the memory-leaking software. The memory leak was real and completely irrelevant.

That one fact, the missile blows up, decided everything. The company had it, so they could tell at a glance which problems were problems and which weren’t, the consultant did not have this. My stakeholders didn’t have the equivalent, so they couldn’t. I’d walked in and described the leak without ever mentioning that the missile explodes.

Give people the big bang first. Most of the noise sorts itself out once they can see where it all ends.