Web developers and Cognitive Biases

In this post, we are going to take a look at some of the cognitive biases web developers, especially front-end developers fall victim to and eventually leads to some bad decisions which costs them badly at their work.

Cognitive biases are basically thinking errors and bad judgments made at the peak of emotional influence due to a variety of reasons.

This post is more of an exploration of sorts on how we, developers and engineers unconsciously succumb to cognitive biases and thinking errors, in making decisions required for our day-to-day job.

The inspiration for this post came after I finished reading books like The Art of Thinking Clearly by Rolf Dobelli and Influence by Robert Cialdini. I wanted to analyse, observe and aggregate the various biases we have as part of our decision making at work. Most of the examples are inclined towards Front-end development, but I am pretty sure that these biases apply equally well to all the domains in web development, like back-end, devops and so on.

Social Proof

Social proof is also known as herd instinct. This is one of the most common cognitive biases prevalent among developers.
This bias is defined something like

Individuals feel they are behaving correctly 
when they act as the same as other people.

In the frontend world, the more people who use a certain JavaScript framework, the more we regard or consider the framework to be a better one than the others.

Everyone else is using it, so it must be the right framework for our project. This bias also plays it's part in times of uncertainty. When you are not certain about your choice, it makes sense to go with the crowd. The social evidence exerts a big influence when you are not certain about your choices.

Sometimes it plays out like, I don't know which tool to choose, so I am going to choose the most popular one and live with it.

Default Effect

The Default Effect is also known as the Status-quo Bias.

The Default Effect is a strong tendency to cling to the
ways things are, even it puts us at a disadvantage.

It is the tendency to always bootstrap a new Front-end project with the create-react-app even though there are more better, efficient and performant tools now available in the ecosystem.

It is the tendency to use the status quo framework like React or Angular though there are better options available to choose from.

This is because we don't want to invest too much time and effort in choosing the right framework for our project. It's just simple and plain easy to go with the safety of the herd, even though the nature and requirements of our projects vary in a wide variety of aspects.

Even experienced developers and senior engineers is prone to fall victim to the Default effect when they want to avoid the time investment for choosing the right framework or tool for the job.

Swimmer's Body Illusion

Does React make your front-end awesome?

This is a tendency to confuse selection factors with
results

Choosing the right tool is just a starting point, job only half-done. Just because you have decided to use a framework or library doesn't necessarily means that, it is going to solve all your problems. It is just a means to an end.

Swimmer's body illusion is the tendency to arrive at a false causality such as "React helps us to build awesome front-ends, hence all awesome front-end projects use React".

Authority Bias

Don't write tests merely for improving coverage

It is a deep-seated sense of duty to authority within 
us all.

I am just using this framework or library because that's what the management told us to use it. Or it may be a top-down decision undertaken by the people in authority like Executives, Managers or Architects.

This is a state as result of unverified trust on the expertise of the authority in question.

Whenever you are making a decision, think about which authority figures might be exerting an influence on your reasoning. And when you encounter one, do your best to challenge, by trying to find the dis-confirming evidence.

Availability Bias

Why we prefer Webpack to no bundler at all?

The tendency to create a picture of the world using 
the examples that most easily come to mind.

It is the tendency to prefer wrong information to no information. With the availability bias, we tend to make wrong decisions and poor judgments solely based on the data available or presented to us.

For front-end developers, it is like going after the popular frameworks, npm downloads, highest starred GitHub repositories, making crucial decisions based on popular surveys. Just because a framework or library is not popular or high-rated, that doesn't necessarily mean it is bad or unworthy.

Sunk cost fallacy

Why you should move away from jQuery?

Sunk cost fallacy is most dangerous when we have invested a 
lot of time, money, energy or love in something.

This investment becomes a reason to carry on, even if we are dealing with a lost cause.

Most of the time, the sunk cost fallacy can be seen within teams or organizations who might have started off with an old and inefficient platform of convenience and are very reluctant in changing or upgrading the tech stack for business and other similar reasons.

They have to scrap it and migrate as fast as they can because they're only throwing good money after bad. It's easily said than done. It is obvious that organizations accumulate so much tech-debt and maintenance tasks, that they never gets prioritized or see the light of the day.

By initially choosing a platform of convenience your company has dug themselves into a potentially dangerous maintenance sinkhole. So stop digging and start building an escape ladder.
-- StackOverflow comment

Not-Invented-Here Syndrome

NIH Syndrome is a tendency that causes you to fall 
in love with your own ideas.

This is a quite uncommon tendency of some organizations and developers to build their own tools, libraries and frameworks in-house typically by reinventing the wheel again and again.
This causes so much waste in cost and effort since there are already efficient and battle-tested tools are available in the market, they just need to pick the right one for the job and use it.

This is typically with some closed-source organizations not very keen on using or giving credit to open-source tools and libraries. They make it a policy to restrict developers from using open-source code in their internal projects.

Survivorship Bias

Why should you checkout archived Github repos?

People systematically over-estimate their chances of success.

This is the tendency to reinvent the wheel. I myself fell victim to this bias a lot of times in my early career. Being an open source contributor, I used to think to create more new libraries and tools, not quite sure how much useful they are to the general public.

It is only after a point of time I realized that open source is not only about creating new and shiny things, it is much more important to support and sustain the ecosystem.

A lot of new people coming into open source think about creating the next hot JavaScript framework or library on their own name and publishing to the npm. GitHub is littered with hundreds of thousands of archived/ repositories. So is npm with a lot of abandoned and orphaned packages not updated in years.

Before you decide to create a new tool to solve a common problem with a new library or framework, think twice how you can do without it. You can open an issue in an existing package or create a pull request for the issue or even review the existing pull requests. A lot of open source maintainers (including myself) are struggling to keep their packages updated, well documented and issue free, we can do a lot better if we have the full understanding of the influence of survivorship bias in our thinking.

Clustering Illusion

Why automation sucks for edge cases?

The human brain seeks patterns and rules. 
In fact, it takes it one step further: if it finds no 
familiar patterns, it simply invents some.

The tendency to automate the most boring tasks often invites some troubles with our pattern recognition abilities. We find a pattern and decide that if we write an automation tool to just address only such patterns, we think that our job is done. But oftentimes, we overestimate our ability to recognize patterns and completely ignore the edge cases or dis-confirming evidence. Only at the last minute we identify the myriad of ways that our solution to the problem at hand is more complex that it looks.

Action Bias

Why looking at architecture diagrams is torture?

The tendency to look active, even if it achieves nothing.

This happens when you immediately start attacking a problem by writing code instead of thinking about it and coming up with a design or architecture to have a proper understanding of the problem statement. In such circumstances, we feel compelled to write code as soon as possible. There are some conflicting arguments about this process such as, this approach might work for small projects and not for large ones.

The action bias causes us to offset a lack of clarity with futile hyperactivity, and comes into play when a situation is fuzzy, muddy or contradictory.

Organizations at large still prefers developers who are quick responders than those who prefer a sensible wait-and-see strategy. Or whether it could be more appropriate to say, organizations celebrate fire fighters rather than fire preventers.

Neomania

Disregard the brand new JavaScript framework

The mania for all things shiny and new

This particular bias has been discussed so many times in all possible forms of literature, blogs, books, articles and videos. Yet we fall prey to this bias more often than we think. It is the tendency to systematically choose or adopt shiny new frameworks, libraries or tools and the need to replace the existing old stuff with the brand new.

This is also partly due to the highly volatile nature of the current JavaScript framework ecosystem, the web development and front-end domain in particular.

According to this post using Stackoverflow statistics, on average, the life cycle of smaller JavaScript frameworks is about 2 years and the bigger frameworks dominate the market for as long as 8–10 years.

Future updates

I am planning to continually refine this post by constantly adding new biases or updating the existing ones with some more examples. My intention here, is not to degrade some popular frameworks or libraries, but to point out the limitations and fallibility of our thinking in making those decisions without giving a rational thought process.

Please let me know your thoughts and feedback in the comment section, if you feel that there are also other biases in play, please feel free to add them in the comments, so that I can add it to the list here.

References

https://stackoverflow.com/questions/2163591/how-to-determine-a-development-strategy-change-from-the-middle-management/2163646#2163646

Books

The Art of Thinking Clearly by Rolf Dobelli
Black Swan by Nicolas Nassim Taleb
Influence by Robert Cialdini
Thinking Fast and Slow by Daniel Kahneman and Amor Tversky

Blog