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.
Related Posts
- https://dev.to/andylim0221/the-art-of-thinking-clearly-book-review-4h0k
- https://dev.to/gtanyware/cognitive-bias-and-software-engineering-4cci
- https://dev.to/frosnerd/ten-cognitive-biases-to-look-out-for-as-a-developer-3bjm
- https://dev.to/x-team/12-hurtful-cognitive-biases-and-how-to-overcome-them-2m9j
- https://dev.to/johnpaulada/sense-driven-development-443
References
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
Top comments (12)
I don't think survivorship bias is over-estimating your chance of success. It's judging what works only on successful things.
The cannonical example being planes that made it back in WWII being the model for where the plane body should be reinforced, which was not helpful because it's the planes that don't make it back that tell you where the problems are.
So in web development that would be akin to using projects that have never been hacked as your model for where to harden security.
It's the projects that get hacked that reveal the weaknesses.
Great comment, thanks for that WWII planes trivia :)
Thank you for writing the article!
While being aware of the biases can really help, I am missing some perspective in some of the examples. My job (apart from being a programmer) is to lead a team of developers and be responsible for all technical things in a company. This requires me to think about things differently than when I was purely a developer:
While applications are started only once, the real trouble comes after a few years. To battle real world problems we have quite a lot of restrictions regarding external libraries and frameworks.
Most of you examples (or explanations) do not take 'the long term' into account. It would be nice if the examples would consider projects that live for a long time in the context of a company.
Yes I agree, long term perspective is one which is definitely an important consideration, thanks for pointing it out. Though I would like to understand how the time frame would alter the thinking process or support the bias in question. Is it okay to have some biased thinking for long-term strategy?
Yeah, in some cases it slightly changes how much of the bias you want to resist. A few thoughts on a few biases you mentioned:
Social Proof
In your post, without saying it explicitly, it comes across as: "Everyone else is using it, that does not mean it's the right choice". In the context of long term organisational survival it is actually most often best to use something that is widely used, even if it's not the best.
Default Effect
This can actually be good. It's worse if you have to support 10 different stacks. We have the rule to keep about 2 stacks maximum. We only introduce a new one when we phased out the oldest version. On top of that it should be 'a lot' better than the current version to compensate for the training, learning curve and future migration.
Authority Bias
It's good to question why. However at some point you know all tools within the company are selected carefully and at that point it is ok go with the bias.
Availability Bias
Working with freelancers can positively influence this. While they might like to learn something new, it also comes at a cost.
Sunk cost fallacy
This is a tricky one. I am the first to say: "It does not matter we have invested a lot in this, it does not bring enough anymore". It's however very hard to find a balance, sometimes you keep old things because upgrading does not bring more than it costs.
Not-Invented-Here Syndrome
We have our own forms and routing library. Two examples where there are popular community versions. It's not bad to roll your own libraries, even if there are pretty good examples. I often encourage my developers to write their own code first before searching for a library, this ensures that they understand what they are looking for. People also tend to forget the cost of introducing an external library, if your site lives for 5 years, the thing you introduce needs to be maintained for 5 years as well. On top of that, some popular choices for common things are actually not as good as you might think.
In any case, I would say this would be a good process: hack something together to get an understanding of that you need, search for a library that is close to what you need, if you can't find a suitable library (where suitable includes long term thoughts) roll your own (preferably open source).
Some good points, but looking at the examples that you give I think that in many cases these decisions/choices are down to practical reasons.
For instance, maybe people use CRA, even when marginally better choices are available, because CRA does the job and you don't lose time on retraining or relearning for another tool.
It's good to be aware of these potential biases, but there may be a multitude of reasons why in a certain situation a dev or an organization might choose this or that tool or option, it might be just a matter of practicality.
You introduced another bias :-)
It's not only the "Webdeveloper" who suffers from these side-effects, just use "Developer" and you're more right than ever.
Another one for you, which I encounter a lot because I'm a Principal Engineer: Because he has more experience, he must be right. (But then they forget I'm also a human). It will cause the one with an idea to shut up, afraid of having a "stupid" idea.
And another one. I won't ask my question, because they might think that I don't understand it yet (... or think I'm stupid). But the truth is, that you should not be afraid to ask a question about something you don't understand, because then you learn. People can't read minds, so speak up and let us give you our wisdom, so that you can be a more valuable team-member.
Yes, that's definitely some narrow-minded thinking from my part. Apologies. I agree with you on the "Developer" label, but I think it would be great if we don't target a particular set of people for these thinking errors. I think these biases applies to all human beings as a whole.
Nice post, you should also check out The Cognitivie Bias Podcast by David Dylan Thomas.
Sure, will check it out definitely. thanks for sharing.
I personally like your examples, although they might be biased as well. Thanks for the article and for linking to the sources!
biases... biases... everywhere biases...
but in Tamil Nadu I thought you were more spiritual ;)
visualcapitalist.com/50-cognitive-...