Cognitive biases refer to the rules of perception and behavior we have learned. Basically, they’re mental shortcuts that we automatically use during our lives. These hidden prejudices can sometimes surprise us in unpleasant ways during our work, and so it’s important to know how they work and consciously try to avoid them. In this article, we’ll have a look at the 5 main biases and useful techniques which can be used to minimize them.
Optimistic bias is a tendency to be overly optimistic about encountered events. In the world of software it mainly affects estimates of how demanding certain tasks are, where one could have a tendency to overestimate one’s abilities.
As an example, during a meeting a colleague might claim that they can take care of some task easily and that it won’t take almost any time. And yet, they know almost nothing about what the task entails and they’re just basing their claim on excessive optimism. As you have quite probably seen, in the world of software these optimistic estimates can often turn out to be very far from the truth. And the cherry on top is so-called easy-difficult bias, which refers to when people assess difficult task too optimistically while viewing easy tasks with too much pessimism.
One method to avoid this kind of cognitive bias is to ask the following direct questions:
Do you see something about the task that could cause problems?
Do you see any reason why your solution might be incorrect?
Did you ever think about the dependencies that could be affected by changing this code?
Confirmation bias is another well-known form of bias. It means that we have a tendency to pay increased attention to the information which confirms our existing beliefs and opinions while suppressing information that goes against these. Basically, it’s like having one’s head in the clouds and running from reality. This form of bias does not have any kind of positive impact on our mental capabilities – quite the opposite, in fact.
As an example, let’s say that a programmer in the team firmly believes that heritability was always a foundation of OOP. Another colleague then presents an argument for why this is not true. Heritability was not accepted immediately, and is still a source of debate. The first programmer, aiming to show that they’re right, might google something like “inheritance as a foundation of OOP” and the very first hit reconfirms their belief. However, in reality their colleague was right. Not even Alan Key, one of the founders of OOP, wanted to implement inheritance in the first version of the Smalltalk language.
Luckily, there are ways to avoid confirmation bias
Try to search for problems which could occur, instead of focusing only on positive cases. So, in the example above, try also searching for the opposite opinion.
Searching for a logical basis for each bias or prejudice (and ideally identifying these as prejudices) and also searching for cases in which they could be logically invalid.
Anchoring refers to the natural human tendency to make decisions based on a single piece of information or fact, and have this then form as a basis for further decisions. However, the initial piece of information might often not be relevant at all and may negatively impact our assessments.
To give an example of this kind of bias, consider the following situation. While trying to assess how much work a certain task will require, the scrum master asks their team: “How long will this task take? 2 weeks?”. Because of anchoring, most of the team could agree that the task would indeed take 2 weeks regardless of how difficult the task actually is. They were influenced by the first piece of information they got. The same technique is also used during interviews, where it is crucial for the applicant to be the first to propose their salary.
So, how do we suppress anchoring?
Instead of asking about the estimate, ask about the task itself: “How much will you manage to do in 2 weeks?”
Planning poker – all opinions are provided anonymously and simultaneously. It’s a great technique for scrum estimates!
The bandwagon effect is a phenomenon which pressures individuals to go with the crowd and accept opinions they see in others. It can also be seen in the context of fashion trends – just consider today’s instragram culture of characterless people. If an idea is shared by most of the population, it becomes more credible regardless of whether it is true or not. Social networks such as Twitter and Reddit are also very prone to facilitating this bias. On Twitter this is further reinforced by the character limit, which indirectly helps spread superficial opinions and ideas.
In the context of software development, let’s consider another example from a hypothetical meeting. A charismatic team leader is giving arguments why the whole team should switch from REST API to GraphQL. In her presentation, she’s demonstrating the technical advantages of the new technology for the whole company. Colleagues also seem interested in switching to the new technology. But unfortunately it’s just the bandwagon effect. In reality, the team leader only caused a commotion around a new technology, but did not justify the value of her idea. Will it interest customers? Will there be any difference when using the technology? Will it bring more time, customers or money to the company? As far as new technologies go, of course these are exciting.
But how can we get rid of this cognitive bias? By asking the following questions:
We develop software primarily to support a company. There’s no reason to use a new, fresh technology if it doesn’t bring any added value?
What’s the added value of this idea?
How will it lead to new customers, saved time or other advantages?
Do its benefits outweigh the cost of implementation?
Attribution error refers to a bias of the attribution process. It manifests by having a tendency to place, when explaining the behavior of another person, too much emphasis on their character while underestimating their situation or environmental influences.
To give an example of the last kind of bias covered in this article, we’ll leave the board room and go back to our work. However, when programming we notice an ugly block of code. We then use git blame to find out who wrote it. It’s Lukáš. Well, of course it’s him. Lukáš is unreliable, impulsive and careless. He doesn’t think about what he’s doing. You would never make the same mistake!
Then you calm down and continue implementing your feature. After a while, you find another block of terrible code. Clearly, another of Lukáš’ “masterpieces”! But this time git blame tells a different story – the author is none other than you. At that point your mind is flooded by a barrage of questions. Am I a bad developer? Am I like Lukáš? But you quickly push these doubts out of your mind, and start coming up with excuses. Of course I’m not a bad developer, we had a deadline and there wasn’t enough time, I had a cold, and my dog was at the vet. That’s what attribution error is all about – underestimating the context of other people’s lives when assessing their actions.
How to avoid attribution error?
Well, blaming the author won’t help. Try to find out what led to the bad block of code.
Maybe Lukáš doesn’t have enough experience in this area of the project or this part of the programming language?
Was he stressed? Was there a looming deadline? Was he overworked? Maybe there was a weekend crunch?
Let the devil’s advocate in
And that’s it – the 5 main cognitive biases. What did we learn? Cognitive biases affect each and every one of us. What we can do to avoid them is to learn to identify and suppress them. The most frequently occurring biases in software development are optimistic bias, confirmation bias and anchoring. But the bandwagon effect and attribution error are also very common. These can have catastrophic impacts on software projects. The main way to avoid them is to always give the problem a proper thought and play the devil’s advocate when analyzing it: try to focus not only on positive cases, but also on negative ones and counterexamples. For more information about cognitive biases in software development, I recommend taking a look at this study which I used as the source for this article. I hope you liked it, and until next time!