by Leon Rosenshein

Biases: The Tyranny Of Or

tyranny of or agile decisions planning biases

I’ve mentioned the Tyranny of Or many times, I talked directly about it four years ago, and I stand by what I said. However, because OR is such a loaded word there’s more to say. And, I get to use the Agile Manifesto and how it’s often mistakenly applied as an example.

To recap, the Tyranny of Or is any time you are forced into, or have convinced yourself, that you are in a situation where you need to make a choice between two options. For example, you’re standing at the checkout counter and there are Snickers bars and Milky Way bars. The cost the same, and you only have enough cash for one of them. So you force yourself to choose. Snickers OR Milky Way. You must choose one. There is no other option.

The thing is, there are other options. It’s often just a bias that we use to fool ourselves. To avoid having to spend the mental energy to make a more thoughtful, nuanced, decision. Yes, sometimes the choice truly is “or”, but very often it’s not.

Consider the candy choice. There are also Kit Kat, Almond Joy, and M&M’s (both plain and peanut) options. You could buy them instead. Or you could by nothing. You might only be able to buy one, weren’t actually limited to the original OR. There might even be a smaller version of each, where you could buy both. Maybe you can turn the or into an and. Here’s another option. Put something else back and get both full-size candy bars. You only think you must choose one. It’s a false dichotomy.

Then there are things that we simplify into an OR. Consider the principles of the Agile Manifesto.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The people who came up with that list we very careful about how they worded it. The didn’t say Left good. Right bad. The didn’t say instead of. They very clearly said

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

They value the things on the left over the things on the right. They didn’t say working software instead of documentation. They didn’t say responding to change instead of following a plan. You can do both. Make things work, and document the why’s and the why not’s. Respond to change, but have a sea chart with a clear goal. You might not know how you’re going to get there, but you do need to know where you’re going. Even if the goal might change over time.

When you’re faced with a value choice, it’s very easy to simplify it into an or. Doing only A or B is easier to explain, discuss, and reason about than 70% of A and 30% of B. Is that the right percentage? Are you actually hitting that exact percentage? How can you make sure a group agrees on those things? That’s way more cognitive load than “We’re doing A and only A”.

Software engineering is Engineering. That art of the possible. The compromise. Because It Depends. It’s always context dependent and nuanced.

So next time you think you’re forced to make a choice between A and B, check your assumptions and check your biases. It might really be a choice between A and B. But it might not be.