“Today’s MVP is tomorrow’s legacy software.”
(Richard Seidl)
Additive bias is our tendency to solve problems by adding something rather than taking something away. In software development I run into it all the time. I work a lot with larger companies that have been building software for a long time, and when I look at their systems and applications, I see an incredible amount of complexity in both business logic and technology. And something new keeps getting bolted on, “because we need it”. Sometimes I wonder what all of this costs.
The overhead of building yet another piece of business logic into these complex structures: is it even worth it? Is there ever a return on investment? Nobody can answer that anymore, because the flows of cost and effort are far too opaque. And yet these companies still make money, otherwise they wouldn’t exist anymore. I find that hard to square. So how does a software behemoth like this grow over decades? One thing up front: it’s not a question of technology. Software monsters like these exist on mainframe systems, and they exist with microservices too.
Tendencies and Prejudices: What a Bias Is
As humans, we are subject to certain tendencies and prejudices. The term for this is bias. A classic is confirmation bias: we tend to look for and interpret information that confirms our existing assumptions and hypotheses. Or affinity bias: we like people who are similar to us or share our preferences. The list goes on. And let’s not forget that these biases have always served a purpose, in life and in evolution, and they still do.
What Is Additive Bias?
Research on additive bias is fairly recent. It says, backed by studies, that when we solve a problem, we would rather add something than take something away. Even when taking something away would be the better, cheaper solution. It starts at school: for most people, adding is easier than subtracting. The reason could be quite simple. Adding takes less cognitive effort than removing. The brain is saving energy.
The first time I read about it, it hit me like a bolt of lightning. That is exactly what we do in software development, and on several levels:
- Business features get added instead of existing ones being adapted or removed. Someone might still need them. Or you would have to analyze a lot of impact. Who knows whether everything will still work afterwards.
- The same goes for the code itself: if it’s complex, the architecture is so-so and the unit tests are more for show than anything else, we’d rather add one more if statement than refactor the function.
- And it’s no different in testing. Delete test cases? No way. Better add another one. We put so much energy into them, after all. But do those 1,000 automated test cases even find bugs? Well.
And just like that, there they are: technical debt and complexity. Or gone: maintainability, testability, clarity.
Feature Fatigue
It’s not only software projects that suffer from this. Users do too. Feature fatigue describes the dissatisfaction, frustration and overload users feel when faced with too many unclear features.
As a consumer, I can maybe switch to a different app quickly. For users of business software, it’s harder. A clerk has to use whatever they are given, whether they like it or not. Whether they enjoy the tool or are happy with it doesn’t matter.
Leaving Things Out as a New Quality
As a coach for dev teams, I find this a really exciting aspect of software quality: what can I leave out? It fits into many of the quality criteria: simplicity, operability, maintainability, usability, user experience, testability and so on. I hardly know any companies that take the topic seriously. Apple did this at times, in grand style (cutting off old habits), but even there, every iPhone generation gets more overloaded.
I think awareness is the first step. And then it’s time to start decluttering. Because less is often more.
PS: A few weeks ago I did a decluttering challenge and got rid of around 700 items from my household, plus lots of digital artifacts. The result: it’s a relief to have more space again. Will we manage the same in software?
Frequently Asked Questions
Why does enterprise software, as it grows over decades, become an unmanageable behemoth?
Because new features are constantly being added “because they’re needed,” without anyone being able to calculate the costs involved. In large companies, this results in a nearly unmanageable amount of domain knowledge and technical complexity. It’s no longer possible to determine whether the overhead involved in integrating yet another feature into these structures will ever pay off: the flows of costs and effort are too opaque.
Does a modern architecture like microservices prevent software from becoming a monster?
No. Software monsters aren’t a matter of technology. They arise just as easily with monolithic systems as with microservices. The decisive factor is the habit of solving problems by adding more: new business logic instead of adaptation, an additional if statement instead of refactoring. The architectural decision alone does nothing to change this pattern.
Why do teams find it harder to remove features than to add new ones?
This is due to additive bias: People prefer to solve problems by adding rather than by removing, even when removal would be the better and more cost-effective solution. Studies support this. One plausible explanation is the lower cognitive effort involved. Subtraction requires more mental effort than addition, even back in school.
Where does this tendency to add manifest itself in software projects?
On three levels. From a technical perspective, features are added rather than adapted or removed because otherwise impact analyses would be necessary, and no one knows if everything would still work afterward. In the code, when the architecture is weak and unit tests provide only superficial coverage, developers would rather add another if statement than refactor the code. And in testing, test cases are added rather than deleted.
Why do automated test case collections keep growing instead of being streamlined?
Because energy has been invested in every test case, and deleting one feels like a loss. So it’s easier to just add another one. Whether 1,000 automated test cases actually find any bugs is rarely checked. The result is technical debt and complexity, while maintainability, testability, and clarity are lost.
Why is too much functionality a bigger problem for users of business software than for app users?
“Feature fatigue” describes dissatisfaction, frustration, and feeling overwhelmed by too many unclear features. As a consumer, you can simply switch apps. An administrative staff member, on the other hand, has to use whatever is provided, whether they want to or not. Enjoyment and satisfaction with the tool often play no role in the selection process.
Can Omission Be a Quality Characteristic of Software in Its Own Right?
Yes. The question “What can I leave out?” can be linked to existing quality criteria: simplicity, operability, maintainability, usability, user experience, and testability. So far, hardly any companies have taken this topic seriously. Even at Apple, where a willingness to break with tradition was visible at times, the devices are becoming more and more cluttered with each new generation.
