Additive Bias - The Great Drama of Software Development

“The MVP of today is the legacy software of tomorrow” - Richard Seidl

Well, there are several. But one thing always stands out. I work a lot with larger companies that have been developing software for a long time and when I look at the system and application landscape, there is an incredible level of complexity in terms of specialist knowledge and technology. And something else is always being added “because you need it”. I sometimes ask myself what it all costs.

The overhead of incorporating any kind of technicality into these complex structures: Is it even worth it? So is there an ROI at some point? Nobody can answer that anymore, the cost and expense flows are far too opaque for that. But: these companies still earn money, otherwise they would no longer exist. It’s hard to get my head around that. But how does such a behemoth of software develop over decades? First of all: this is not a question of technology, such software monsters exist not only with host systems, but also with microservices.

Tendencies

People are subject to certain tendencies and prejudices in life. The English term for this is bias - I haven’t found a suitable German term yet. A classic: confirmation bias. We tend to look for and interpret information that confirms our previous assumptions and hypotheses. Or the affinity bias. We like people who are similar to us or have similar preferences. The list goes on and on. Not to forget, these biases have always had and still have their purpose in life and evolution.

Solution strategies

Research into the additive bias is relatively new. This states - and has been backed up by studies - that we would rather add something to a problem solution than take something away. Even if “taking something away” would be the better, cheaper solution. And this is already the case at school. For most people, adding is easier than subtracting. The reason could be quite simple: The cognitive effort involved in adding is less than in subtracting. So simply: brain energy saving.

The first time I looked into it, it hit me like a bolt of lightning. We don’t do anything differently in software development, and on several levels:

• Specialisms are added instead of adapting or removing existing ones. Someone might still need it. Or you would have to analyze a lot of impact. Who knows whether everything will still work.
• Also in software development: If the code is complex, the architecture is so-so and the unit tests are more of a sham than a reality, then it’s better to add another if instead of refactoring the function.
• And the same goes for testing: delete test cases? No way. Better to add an extra one. We have put so much energy into it. But will the 1000 automated test cases even find errors? Well, yes.

And then, poof, there they are: the technical debt, the complexity. Or gone: the maintainability, the testability, the clarity.

Feature Fatigue

But it’s not just the software projects that have a problem with this. The user does too. Feature fatigue describes the dissatisfaction, frustration and excessive demands placed on users by too many and unclear features.

As a consumer, I might be able to switch apps quickly. But for users of business software, it’s more difficult. A clerk has to use what they are given. Whether they want to or not. Enjoyment and satisfaction with the tool are irrelevant.

A new quality

For me as a coach for dev teams, this is a very exciting aspect of software quality: What can I leave out? I can include many of the quality criteria: Simplicity, operability, maintainability, usability, user experience, testability, etc. I hardly know any companies that take this topic seriously. You could observe this in part at Apple (cutting out old habits), but even there iPhones become more overloaded with every generation.

I think awareness is the first step. And then start clearing out - because less is often more.

PS: I did a clean-out challenge a few weeks ago and removed around 700 items from the household, plus lots of digital artifacts. Result: It’s a relief to have more space again. Will we be able to do the same in the software?