Cognitive Bias in Software Development
Human brains are amazing machines, but they’re not perfect. Our software development projects are often compromised by what psychologists call “cognitive bias”, a category of cognitive processes that cause imperfect decisions and judgements.
Why aren’t we great at estimating time and cost? Why is group decision making often flawed? Why do we sometimes put off that really valuable minor refactor, or that useful doco? And why, at the post implementation review, are we all suddenly experts on what went wrong?
Level up your ability to identify cognitive biases and fallacies like status quo bias, planning and sunk cost fallacies, groupthink, and hyperbolic discounting as they happen, and get equipped with strategies to beat those biases before they beat you.
[Full house for this talk! I missed the first couple of minutes trying to find a patch of floor to sit on…]
[wording may not be quite right:] Cognitive bias – systematic failures or problems of thinking common to all humans.
Five common problems for teams:
(1)
Planning fallacy: tendency of individuals to display an optimism bias and underestimate the time and resources required to complete a project.
Example: the Sydney Opera house – estimated $7m cost, final cost $100+m
This is basically what happens in software too.
Are people motivated to estimate well?
Term: Planning focalism – thinking a task is unique, not similar to tasks completed in the past. Tshirt sizing is a great way to move away from this problem.
Three types of info:
Reference Class Forecast can help sort this out. Ignore details that distract from an accurate estimate.
Postmortems are common – we do retros, postmortems etc… but what about a Premortem? Get people together and imagine you’ve executed the plan you have – and what went wrong? This unlocks peoples thinking, lets them find the risks, legitimises doubt and lets people speak out.
(2)
Group think: the tendency to favour group harmony. This means people don’t challenge ideas, instead they just follow along with the majority or the leader.
How to combat this?
(3)
Confirmation bias – if you asked this room where “the nearest apple store” is, they wouldn’t send you to a fruit shop! We see things through our own lens. This is why we don’t test our own code.
So flip the framing of questions. Instead of “is x true” ask “is the opposite of x false”.
Assign someone to the devil’s advocate role. It can actually be quite amusing!
(4)
Hyperbolic discounting – tendency to prefer smaller payoffs now, over larger payoffs later. We discount future value that requires sacrifices in the present.
“I’m definitely going to come back and document this later… I’ll refactor this later…” This is where technical debt comes from.
You don’t have to do everything now – but you do need to ask the questions.
(5)
Sunk cost fallacy – tendency to honour previously expended costs over future benefits.
Have you ever finished a book despite thinking it’s a bit crap? Ever finished a feature even though the future need and value has gone? “We’ve gone this far…”
We are wired to hate waste, we don’t like throwing away effort. We don’t like to get rid of things even when they are useless.
To reduce the impact, get clear on options and outcomes.
