Subtractive change

People i work with realize very soon, that there is nothing more that i love to do, than reduce complexity - in code, structures, tools, process... I can't claim that i do this always or it is always successful, but when it is this is just amazing. Taking everything apart and building it up again while dismissing many many unneeded details - it's a dream. When other developers encounter me doing that to code they cared for for years, they are usually somewhat estranged and flabbergasted, but i usually win them over to embrace the change.

But all in all removing details - so called subtractive changes - is not a practice which is very common in our business. Rather than reduce the code base we just add some more classes and abstraction levels; rather to reduce the amount of product features we are adding more and more features; rather than reducing dependencies we eagerly invite any new dependency; rather than keep teams at a healthy size we add more and more people; rather than questioning our documentation we add more; ... I could go on and on with this, you get the picture. You probably have experienced this effect in some kind in your environment, changes are that sometimes you are even the driving force of adding complexity.

Now this pattern seems to appear on every level and it just seems typical, but in the long run this is not healthy - for your code, the product, the organization, and even for societies and our ecosystem. Every bit of complexity adds some cost to keeping the system alive. Every bit of complexity makes it harder for the system to change into a less unhealthy state. And it is deeply frustrating when you realize this unhealthy state and want to improve it, but you are not able, since complex systems have a tendency to self-stabilize. At least this is something that i encounter from time to time and also recognize in the work mode of others.

When i was talking at work about such fallacies my product manager dropped the following paper: People systematically overlook subtractive changes. If you can access this paper i strongly recommend you read it in detail - it's worth it. Here i will just paraphrase on the main messages of the reported research.

For this paper the authors conducted a series of various behavioral experiments, which all shared a common theme: A problem was posed that has several solution, some by subtracting features (subtractive), some by adding features (additive). In all the problems subtracting features was the easier and simpler solution. However in ALL experiments the participants preferred solutions that where additive and did not even realize that there are subtractive solutions available. Seems familiar, doesn't it? There are several likely reasons for this default mode of thinking - training, social enforcement, risk reduction, ... - which this paper does not explore further. The experiments introduce some covariates that have an impact on the selection ratio of subtractive strategies. Instructions have an impact: If the instruction clearly state that subtraction is an option, participants were more likely to choose a subtractive strategy. Experience has an impact: If participants had the opportunity to train on comparable problems to explore the solution space, they were more likely to discover subtractive solutions. And stress has an impact: If participants had higher stress levels while performing the task, the likelihood that they discovered subtractive solutions was reduced. These three factors changed the ratio of subtractive change to additive change, however in all cases it was still skewed towards additive change.

It is a bit of a stretch to translate such statements from very simple experiments to the domain of software development and organization development - and even further to societies - but i believe that these statements can be very useful in introducing much needed subtractive change to solve the unhealthy complex systems we often encounter. For this little rant i will keep it a the level of software development:

Developers should be taught that subtracting features and code is a valid and valuable option.
Developers should be given the experience of reducing code and functionality.
Developers should not be stressed when searching for the best solution for their business problem.

For me these bullet points translate into some straightforward actions: I have to keep talking about this topic again and again and again, till everybody realize the first point. When i find a good thing to reduce complexity i have to push it to other developers such that they get the chance to experience this. And somehow i have to make sure that my organization is not causing stress to developers (like deadlines, quality milestones, quarterly goals, ...) - actually the last point might be the hardest.

I hope you liked my little interpretation of this awesome paper. Feel free to drop me a message if you do not agree or have some thoughts about it, i am eager to discuss this topic more in depth.

Adams, G.S., Converse, B.A., Hales, A.H. et al. People systematically overlook subtractive changes. Nature 592, 258–261 (2021). doi.org/10.1038/s41586-021-03380-y