We default to addition

I wrote a lot about the staggering complexity in IT, its detrimental effects, and what we can and should do about it (see, e.g., my “Simplify!” blog series. I wrote about the embedding of the complexity problem in a bigger context in my “Responsible IT” blog series). I also identified several drivers that usually increase accidental complexity, i.e., complexity in the solution which not needed to solve the given problem (see the third and fourth post of my “Simplify!” blog series for a more detailed introduction to accidental complexity).

Recently, I realized that there was still a puzzle piece missing. I more or less accidentally stumbled upon that missing piece. On social media, I saw a slide from someone else’s presentation ¹ with the following text on it:

“Our brains tend to default to addition rather than subtraction when it comes to finding solutions”

This caught my attention because it looked like an explanation of why we pile up all that complexity in IT so readily – even lots of complexity we do not need to solve a given problem.

The search for original sources

The slide also included a link to a source I immediately followed. I was a bit surprised I did not find the quote from the slide in the article. Hence, I guess the slide author tried to summarize the article in a few words (and did a very good job doing so).

The article itself felt okay, yet quite superficial. The title was a bit flashy, as well as the name of the media outlet. Overall, it did not feel like a very reliable source of information to me. I was not sure if the contents were oversimplified or maybe even exaggerated for the sake of attracting more attention. Thus, I followed the links provided in the article.

One link brought me to the original paper that was published in Nature. As expected, it was locked behind a paywall. There was an option to buy the article, but it was so ridiculously expensive I refrained from buying it even though I prefer digging down to the original sources over relying on second-hand claims.

Luckily, the article contained a link to another source it was based on. This article did not contain much more detail than the derived one. Actually, the derived article was more or less a bit worse copy of the original article. However, this article was published by the university where one of the authors is a professor, which, in my opinion, gave it more credibility than the one with the flashy title published in a flashy media outlet.

I also watched the 6-minute video embedded in the article, which summarized the findings of the research in an entertaining, easily digestible way you see quite often in the US (no critique, just an observation).

Finally, while looking for more original material, I found another paper (also Nature but this time not hidden behind a paywall) that added some more nuances to the original research. I will come back to this paper later.

In the end, I had a written summary and a video summary of the original research, plus the original paper of some additional research building on the original research and adding some more nuances. I would have liked to have the original paper as well to understand in more detail what the researchers actually did instead of just getting a summary. This is because, in reading a lot of research papers and other original sources over the years, I learned that often subtle details matter that are usually left out in summaries because these details provide otherwise missing nuances you need to put the summary statements into perspective. However, this is what I got, and it had to do.

The addition bias

The general findings of the research were (in my own words):

• If presented with a task, people tend to add things to the status quo a lot more likely than taking things away even if taking things away would result in less effort and/or would have resulted in a better solution.
• The higher the current cognitive load of a person, the less likely it becomes that the person considers a subtractive solution. I.e., the higher the workload, the higher the stress level, the more likely it becomes that tasks are solved by adding things, no matter if subtracting would have been the better approach.

Benjamin Converse, one of the authors of the original paper, phrased it this way:

“Additive ideas come to mind quickly and easily, but subtractive ideas require more cognitive effort. Because people are often moving fast and working with the first ideas that come to mind, they end up accepting additive solutions without considering subtraction at all.”

Leidy Klotz, another author of the original paper, published a book named “Subtract” where he elaborated more on the ideas of the original paper. One of his complementing observations is (in simple words) that the economic and cultural ideal in the US and all countries influenced by the US culture is to have “more”, that “more” is always better. Buying more is better for the economy. Having more is better for one’s status. Etcetera.

This observation fits nicely into the research of the other paper I mentioned before. That paper concluded that we cannot simply generalize the claim that people prefer adding over subtracting. While the claim is generally true, its applicability varies based on factors like task, culture and age. E.g., the authors found out that in Sweden, where people tend to value social equality more than in the US, people tend to lean towards subtractive solutions more often than their US counterparts.

Overall, it can be said that while people tend to have an addition bias, it is not an all-or-nothing thing, but its pronouncedness tends to depend on several influencing factors like task, culture, cognitive load and more.

Applying it to companies and IT

So far, so interesting. But what does that all mean for IT?

Well, we are regularly confronted with situations where things are not as some requiring party wants them to be. This ranges from very general complaints like “Software development is too slow and expensive” to very specific demands like a changed software behavior.

In all those situations we need to act – usually quickly – and this is where the addition bias tends to strike. We hear “Something is missing” and our brains typically translate it to “We need to add something to improve the situation”:

• If we are accused of being too slow, we add more tools.
• If we are accused of poor software quality, we add more rules, tools and checks.
• If an old application cannot be extended anymore, we wrap it in a modern layer that implements the missing functionality.
• If the business department wants a different workflow, we add another workflow.
• If we want to improve the user experience, we add new features.
• If something new – a tool, a technology, a paradigm – becomes fashionable, we add it to the existing landscape.
• If we attempt to homogenize our system landscape, we add a homogenization layer.
• And so on …

Most of the time, we do not even think about the option of subtracting something. We have a problem, and to solve it, we need to add something. This is the usual train of thought, and we are so used to it that we usually do not explore the possibility of removing something at all.

As an aggravating factor, we are under stress most of the time. There is always more to do than we can accomplish. Deadlines are always tight. Pressure in software development is always high. This means we find ourselves in a constant state of high cognitive load and stress, the exact state where our brains tend to switch to autopilot – which in this context means to look for addition because it requires less cognitive effort.

What makes things worse is that companies tend to develop a kind of hoarding mentality. “Do not throw it away. We still might need it” is a sentence often heard in companies. A major reason for this is that people often do not know why something exists and thus are afraid of removing it. This way, the addition bias is involuntarily reinforced.

Additionally, an industrial mindset values output: More is better, as “more” in an industrial market means more revenue. As the industrial mindset is deeply ingrained in the thinking and acting of most companies and thus also in IT, the mere suggestion of removing something often creates a frown.

Sometimes, we even find it encoded in the metrics used to assess the productivity of people. Many of you still know the stories of developer productivity measured by lines of code added. If you think these times are gone, think again. We just got it back with full force through the AI backdoor: “With AI, I became a 10-time developer writing 10 times as many lines of code than I did before.” Here we go again!

And even if the AI productivity gain is phrased differently, it is always about how much more output you produce. It is never about how much you might have subtracted.

Know your bias

For me, the addition bias was sort of a missing puzzle piece. Yes, we are required to change our software and systems every day, and usually the requesters talk about what they are missing. But we could also change our systems in a subtractive way instead of an additive way if it would result in an overall better solution ². Still, we rarely do it. Whenever we touch software, we tend to add things.

The addition bias that (based on the experiments the authors of the referenced paper conducted) hits decidedly hard if under high cognitive load gives an explanation of why most people think about adding first – up to a degree where it becomes part of a company culture.

As I have pointed out, there are more factors that contribute to the fact that we always tend to add things in IT. We also should not overestimate the research results as they contain a lot of nuances and do not apply in every situation equally. Still, I think we can consider the addition bias as a significant contributing factor.

Knowing that we have such a bias makes it possible for us to deal with it because we can only deliberately deal with things we know about. Hence, the next time you get a task and your first thought is to add something, maybe pause for a moment and think if there might be a better solution that involves removing something.

This does not mean that you failed if you do not come up with a solution that subtracts something. Sometimes, probably more often than not, adding things is the way to go. But not always. And it is important to take the time to recognize those situations because subtracting leads to less code, fewer concepts, less complexity.

Or as Lao Tzu advised:

“To attain knowledge, add things every day. To attain wisdom, subtract things every day.”

Maybe he foresaw our situation in IT two and a half thousand years ago …