Categories
Best Practices

The “Theory of the Situation”

Upon my research about how to avoid errors in software development, I came across an interesting article from a NASA workshop. The workshop had the title “Resource Management on the Flight Deck” [1]. It was held in June 1979, and the topic of the workshop was finding new ways to avoid accidents in aviation.

One part of the workshop was taking a closer look om something called the “Theory of the situation” [2]. The main finding in this paper was, that people always have a belief of the situation, they are currently in and what is happening around them. This is called the “Theory of the Situation”. But what’s actually going on might be different. This is called the “Theory in Use”.

For example think of a pilot in an airplane assuming that the aircraft is travelling at a certain speed, but actually the instrument is displaying a wrong value, because the sensors are not measuring correctly. The wrong speed measurement is believed to be correct, so the pilot acts on a “Theory of the Situation”, which is based on a wrong assumption.

This Happens in Software Development Too

Recently, we delivered a set of fixes to a customer. After the deployment, the software still showed the exact same bug. We went through every configuration, every file, every log. Nothing. Five developers looked at the problem – experienced people, all of them – and nobody could find the issue.

It took us an embarrassingly long time to discover the real cause: the fix was never installed on the customer’s system. The git pull had never been executed. We were all looking at the delivery repository, convinced the new version was running – but the old version had been deployed the entire time.

Our “Theory of the Situation” was: the software has a bug.
The “Theory in Use” was: the wrong version of the software was installed.

Five people, collectively blind to the most basic assumption: that the code we were analyzing was actually the code that was running. Nobody questioned it, because nobody thought to. We were all too deep inside the problem.

This is exactly what the NASA paper describes. The dangerous part is not the wrong assumption itself – it’s the fact that a shared wrong assumption becomes invisible. Once everyone in the room believes the same thing, nobody checks whether that thing is actually true.

What I’ve Learned From This

  • If you ever doubt a situation, tell everybody about your doubts. Don’t hide your scepticism.
  • Question yourself and your team whether your baseline assumptions are correct – especially the ones that feel too obvious to mention.
  • If somebody raises a doubt, take it seriously. Be prepared to verify that your “Theory of the Situation” matches the “Theory in Use”. If it doesn’t, adjust your theory.

The most dangerous assumption is the one nobody thinks to question.


The documents mentioned in this post can be found on the NASA Technical Report Server:

By marcus

Deputy Head of Department Technical Components.
Teamlead, Developer and Architect.

Leave a Reply

Your email address will not be published. Required fields are marked *