Biases in software development
This blog post will not be serious post as usual. Today I would like to convey some story of programming and why their happen.
I would like to tell you about some cognitive biases. And especially about our inclination in software development.
Uhh, but first let’s recognize our primary enemy.
In this Wikipedia article, there are a ton of cognitive biases.
Some of them are well known. For example Dunning-Kruger effect.
The tendency for unskilled individuals to overestimate their ability and the tendency for experts to underestimate their ability.
And do you know what is the first rule of Dunning-Kruger effects club? You don’t know that you are the member of this club:)
So in this blog post I am going to tell you two stories where I saw these cognitive biases in a real word.
You know this story very well. Our college created good piece code. He made the reasonable level of abstraction, used small classes and nice functions. Then he left the company.
And now your boss wants to you to add a new feature to this existing code base. You know that this feature is easy, so you make some estimations and start implementing the new feature.
You open the codebase to make some minor changes. But after some inspection of code you begin to grow angry because this class hierarchy is not prepared for this new use case and this code is too coupled So you have to increase your original estimations.
Before you start ranting about the bad code, lack of future prediction and giving statement that this feature is clearly predictable please STOP. You are probably a victim of the bias named Hindsight bias. Or sometimes called as knew-it-all-along effect” or creeping determinism.
What is this bias about:
We usually believe that future event or change has been predictable. But it isn’t true. The word is much complicated than you think. And you can’t assume all customer’s future requirements to our software.
Also, there is one software rule(or principle) that forbid this kind of predictions. It is a well-known principle of extreme programming YAGNI. YAGNI is an acronym for You Aren’t Gonna Need It.
Ron Jeffries said:
“Always implement things when you actually need them, never when you just foresee that you need them.”
What does it mean for us?
When you are in this position that you maintain the other’s code, please be more tolerant and generous. Maybe college’s class hierarchy is after all right, and your opinion is wrong.
Not invented here
You have found a new nice UI library that perfectly solves your problem. You are so excited so you start telling everyone that your company must buy this library, and everyone must start using this piece of excellent software work.
But without any warning, you immediately face the strong opposition. What’s wrong with you people? You start asking yourselves.
You check this library again. You didn’t find anything bad about this library. So you start to argue with your college and trying to explain the features, advantages of your chosen library. But the opposition is still active.
Maybe you came across “Not invented here”(NIH) syndrome.
What does it mean for you?
Not invented here (NIH) is a stance adopted by social, corporate, or institutional cultures that avoid using or buying already existing products, research, standards, or knowledge because of their external origins and costs.
In software development sometimes this syndrome are referred to as “reinventing the wheel”.
The problem with your library is not that it is bad. It can be a cultural or personal problem.
The reasons for opposition to your library can be:
- Your college doesn’t accept it because they can fear of losing control. He or she can’t change the source code, or if it is possible, it can be tough.
- They don’t bother to read the license so they fear that there can be some financial consequences.
- Or they don’t trust the makers of the software. And it doesn’t matter if this library is from a big company or open source world.
I know people who don’t trust anything from Microsoft and also people who can’t accept that open source community(especially one man show projects) can create a stable piece of code.
So if you are in a position of the proponent of new software you need to prepare to face this strong opinions. My advice is to learn this library well and make a presentation about features, advantages, and disadvantages.
And don’t say anything about it to anyone before this presentation. When someone give a strong statement, it can be hard for her or him to change it later.