3 Cognitive biases developers fall for

Over the last weeks I read a lot about cognitive biases: typical mistakes, which people tend to make over and over. And some were scaringly familiar to me as a developer! Taking the right decision is one of the most critical activities in software development, so let’s spend a thought or two on those oh-so-familiar misconceptions.

Ever wasted an hour chasing a bug where you "knew" what caused it, only to find out it came from a completely different area in your app? That might have been Selective Perception at work!

We tend to interpret information in a way that matches our existing beliefs. When you "know what you are looking for", you are less likely to pay attention to information which contradicts your belief. You have to actively look for contradicting information, otherwise your brain tends to filter it out. This also applies to eg. interpreting your web analytics data. Do you expect a rise in the number of sales due to your latest checkout changes? You will likely notice the data which confirms your expectations and fail to take notice of data proving you wrong. That's also why others are much quicker at spotting issues in your own code.

What can you do against Selective Perception?

• realize that information which proves you wrong is much more valuable than information that confirms what you already know
• do some “break the model”-thinking whenever something is easy to interpret: what other explanations exist for what I just observed? If you don't find any, you're certainly wrong. For me that's one of the most valuable exercises to critically check my conclusions.

Explanation: Selective Perception bias
Describes the tendency to interpret information in a way that it confirms our existing beliefs. A classic study for this effect was conducted using a particular violent football match between two US college teams (Princeton and Dartmouth). When supporters were asked to watch a recording of the game, and asked to count rule violations for both teams, the supporters of each team distorted the numbers in their favour. Princeton supporters noticed nearly twice as many rule violations by Dartmouth players than the Dartmouth fans. One Dartmouth fan actually saw no violations from his team at all and asked to be sent the apparently missing footage - obviously, he was quite talented in “selective perception”... ;-)

Sometimes I can get really annoyed when looking at some code where I think “oh damn, this design won’t get us very far, what a stupid developer” - but wait! - how much do I really know about why the developer took that design decision? Maybe there’s an additional change to come which affects the design problems I spotted? Maybe he had valid reasons not to spend more time on it, like fixing a critical production bug instead? Very likely there is a valid explanation beyond “he’s an idiot”.

We tend to overestimate personality-based explanations and underestimate situational influences on other people’s behaviour (interestingly, that’s not the case when explaining your own behaviour). And unluckily this effect is stronger for “negative” behaviour, while being less present for positive behaviour. Psychology uses the term “Fundamental Attribution Error” to describe this bias.

What can you do against this effect?

• Be careful when attributing behaviour to personal characteristics. Talk to the person before jumping to conclusions.
• Make sure people get in direct contact so they understand the context under which the other person was acting. Daily Standups, Retrospectives, Planning Meetings, a communal coffee kitchen, having lunch together - all those face-to-face-events have the positive side-effect of better understanding the context of other team members.

Explanation: Fundamental Attribution Error
Describes the tendency to use personality-based explanations instead of situational ones to explain behaviour of other persons. The classic experiment for this is a study (Jones/Harris, 1967) where students listened to an essay, which was written in favour or against Fidel Castro. Even when told that the opinion of the essay was assigned to the author by coin-flip, the students tended to attribute a pro-/anti-Castro attitude to the author’s personal opinion instead of explaining it purely from the situation. (The exact explanation for the effect described here as Fundamental Attribution Error, is still under discussion, a more recent meta study (Malle 2006) on the related actor-observer-bias suggests it might need a more complex explanation)

So you’ve been discussing this new software component for a long time and finally decided to build your own. Two months of coding later you still don’t see an end, and the project drags on and on. This guy, who was against build-your-own and wanted to buy a ready-made component, tries to kill the project over and over. But no! No way you are going to throw away two months of work and spend even more money on buying that software!

Maybe you are right. But maybe you are wrong and it’s indeed time to reevaluate the former decision: it might turn out that it’s cheaper to buy the component now instead of finishing the build-your-own project. And the two months of work? Should not influence your decision at all.

Using the “we already invested so much time” as an argument is called the “Sunk Costs Fallacy”: seeing all the money - or here effort - that was put into a decision, people tend to stick with it. Even if, from a rational point of view, an alternative is clearly cheaper. In studies this effect was proven to be even more prevalent if you were the one who was responsible for the original decision. 

I personally wonder if this might also be especially relevant with consensus group decisions, where the the emotional barrier for questioning a former decision might be even higher.

So, what might help us to compensate this error?

• As difficult as it is: actively ignore the previous emotional, monetary or time-wise investment you made (but keep the possible learnings you gained!).
• If you feel you’re still attached to that investment, pay special attention to what your critics are saying. They might see the situation more clearly. 
• In everyday-programming you as a pair-programming-buddy should stop your partner from getting stuck in a dead end.
• On the organizational level: help to create an environment where reverting a decision or stopping a project is not seen as personal failure. Failure-blaming environments raise the likeliness to stick to a bad decision.

Explanation: Sunk Costs Fallacy
Basing a decision on the non-recoverable investment made in the past, instead of the expected costs in the future. Psychologists explain the effect as the result of both an overly optimistic bias once you invested in something, and the avoidance of acknowledging loss. Studies often use a classic example where you have paid for a cinema ticket, and then notice that the movie is boring. Do you leave or stay? Most people stay, being afraid to acknowledge the lost money. What do you do with your evening?

If you are still spending time to read this, then maybe you did not understand the previous paragraph ;-) or you actually have some use for the information here. I hope for the latter! If you want to learn more about cognitive biases you can browse through Wikipedia’s wonderful list of cognitive biases. All these biases have positive aspects too, but your decisions will be much better if you become aware of them, so that you can un-bias your thinking when necessary.

Feel free to share the link - especially with your colleagues. It might make life easier for you! ;-)