The Bugs in a Programmer’s Mind
When David Kahneman and Amor Trovsky first published their Nobel prize-winning research on cognitive biases, it was hailed as a landmark achievement in psychology and essentially created the entire field of behavioural economics. This research was subsequently published in Thinking Fast and Slow, one of the most recommended books on any list.
Cognitive biases are bugs in the ‘software’ of our brain. How do you know when you are thinking correctly and when does your mind actually deceive you?
Software engineering, like all professions practised by humans, also falls prey to cognitive biases in a multitude of ways. Here is a short list of such bugs that I have encountered in my career as a software engineer
1. Anchoring and adjustment:
From Wikipedia: Anchoring and adjustment is a psychological heuristic that influences the way people intuitively assess probabilities. According to this heuristic, people start with an implicitly suggested reference point (the "anchor") and make adjustments to it to reach their estimate. A person begins with a first approximation (anchor) and then makes incremental adjustments based on additional information. These adjustments are usually insufficient, giving the initial anchor a great deal of influence over future assessments.
How we see anchoring and adjustment bias in software engineering:
- Arbitrary Deadlines: All deadlines are arbitrary. Work fills up the space you allot to it. Use budgets instead of estimates to build a feature of sufficient quality.
- Incorrect Assumptions: People fill up the missing links in their knowledge with their own sparsely informed data or just make assumptions and miss the correct picture. Lack of readability in production code results in shotgun debugging.
- Missing ‘new’ context: Sometimes solution architects anchor on their previous or outdated understanding of the system and find themselves unable to adapt to a new context. When you hear things like “Java is the best language” or “Java has the best community”, you’re actually witnessing this bias in play.
- Start with ‘Hammer’: Developers and architects also anchor on the initial solution design, thereby failing to quickly address new change requests, budget constraints or God-forbid, market change.
- Embellishing: Developers who anchor on existing solutions instead of solving by first principles tend to include unnecessary features. Errors in the anchors get propagated to new artifacts.
- Overestimate Productivity: Ah, the piece-de-resistance - by anchoring on a lower software estimate, developers and managers tend to overestimate engineering productivity.
2. Optimism bias:
From Wikipedia: Optimism bias is a cognitive bias that causes someone to believe that they themselves are less likely to experience a negative event.
How we see optimism bias in software engineering:
- Knowing vs Understanding: Knowing more about a certain subject can lead to less accurate estimates. This is interesting because it sounds so counterintuitive. When people have theoretical knowledge and not as much delivery experience (Rockstars, I’m looking at you), they tend to be optimistic in their ability to deliver just because they already have validation of their skills.
- Underestimating small: Estimates are more accurate for larger tasks in hindsight than smaller tasks. We developers become optimistic in our ability to ship just because the task is smaller.
- People optimistically estimate difficult tasks and pessimistically estimate easier tasks. This is largely because people lie to themselves about how capable they are of fixing problems that they have not even discovered yet.
- Developers judge concrete near-future risks more accurately than abstract, far-future risks. For example, writing a build-and-deploy script or maintaining an automated test suite is almost always ignored during the design phase.
- Winner’s curse - More often than not, the Most competitive bid is selected instead of the most realistic one, so people bid in no relation to the effective project estimate.
“Reasonable engineer: It will take 10 weeks.”
“Rookie engineer: I can do it in 5.”
3. Availability heuristic:
From Wikipedia: The availability heuristic is a mental shortcut that relies on immediate examples that come to a given person's mind when evaluating a specific topic, concept, method or decision. The availability heuristic operates on the notion that if something can be recalled, it must be important, or at least more important than alternative solutions which are not as readily recalled. Subsequently, under the availability heuristic, people tend to heavily weigh their judgments toward more recent information, making new opinions biased toward that latest news
How we see availability heuristic play out in software engineering:
- People use ‘popular’ keywords into design practice even though it derails their estimate and budget and makes no business sense (Microservice, Machine Learning and Blockchain are among the biggest culprits here)
- People misconnect the dots and try to apply a solution that worked for them in some other problem to a place where that solution may not really apply.
4. Confirmation bias:
From Wikipedia: Confirmation bias is the tendency to search for, interpret, favour, and recall information in a way that confirms one's preexisting beliefs or hypotheses
How we see confirmation bias play out in software engineering:
- Developers only test the happy path. That is,to say they test the program with only consistent data, not inconsistent data
- People only search for familiar areas of documentation and confirm their existing view instead of searching all across the known sources.
- Developers tend to resist or reject change requests that do not ‘confirm’ the already proposed architecture and design.
I’ll wrap up here for now, but if you’re interested in reading more about interesting biases, here are a few more worth looking into. Hopefully they’ll help you understand your own biases and avoid new ones.
- Fixation and framing effect - Inability to curate ‘must-haves’ from ‘nice to haves’ puts everything in the must-have bucket.
- Overconfidence bias - Treating large battles to be as easy as small victories lead people to overestimate their own ability
- Hindsight bias - When people claim that they could predict the inaccuracy in their estimation after the fact as they knew it all along but it didn’t come to their mind.
- Mere exposure effect - People want to keep doing the things that they’ve always done. (“I am a Java developer”)
- Halo effect - Charismatic candidates appear more competitive than uncompetitive ones.
- Sunk cost bias - Developers tend to waste two hours of their time if they’ve already wasted one hour unsuccessfully finding a solution for a problem
- Hyperbolic discounting - Developers tend to hack solutions instead of building for a long term sustainable design change implementation.
- Cognitive miserliness - Uncritically agreeing to whatever requirements you receive.
- Bandwagon effect - People tend to align with the lead engineer’s or architect’s opinion instead of the right opinion.
- Status quo bias - Developers tend to irrationally defend present conditions in order to not to introduce errors.
Notes: