Michel de Montaigne, in his ‘Essays,’ recounts the story of a friend who fell sick. Despite consulting doctors and trying different treatments, nothing worked. Resigned to his fate, the friend finally gave up all treatments and stopped eating. Surprisingly, this led to an improvement in his health.

This incident illustrates the concept of ‘improvement through subtraction’, a principle Nassim Taleb terms as ‘Via Negativa’. Originating from an ancient Biblical notion, ‘Via Negativa’—literally ‘the negative way’—suggests that enhancement often comes from eliminating harmful elements rather than adding new ones.

In a world obsessed with addition, how might we consider the act of subtraction? This post explores ‘Via Negativa’ in software design and life, exploring the hidden costs and unintended consequences that can arise from well-intentioned interventions.

The hidden costs of intervention

As builders of software, our goal is to create solutions that provide real value to our users (and hopefully generate profit). Through interactions and observations, we identify needs and opportunities that our product can potentially address. This often leads us to create a list of new, novel ideas.

However, in our enthusiasm for these new features, we tend to overlook the downstream implications they carry. Costs of new things include but are not limited to:

• Every new thing we add creates a new thing we need to manoeuvre around in the future.
• Every new thing we add increases our maintenance overhead.
• Every new thing we add is a new dependency that needs to be considered for every other new thing we add.
• Every new thing needs to be slotted coherently into new user onboarding and highlighted to existing users.

Eduardo Ferro Aladama beautifully adapted the biological concept of ‘Basal Metabolic Rate’—the minimum number of calories required for basic bodily functions—to the field of software. He introduced the term ‘Basal Cost‘ for a feature, referring to the essential amount of effort or resources needed to maintain that feature’s basic functionality.

It is a lot like agreeing to go to that party next year, you say ‘yes’ today because it feels so far away, until the day rolls around and you hate yourself.

Why do we over intervene?

A few potential hypotheses to consider.

Principle Agent Problem

• Agents (employees, contractors, consultants) want to look busy… “look, I did something!” There is almost a theatrical quality to it. When an Agent’s goals are not directly aligned with the Principle they may attempt to satisfy some obscure goal such as perceived effort or quantity of output (see feature factory). Avoid consultants.

We find positive ideas easy (and seductive)

• Enter any ideation session and you will hear excellent ideas to add new things. “We just need to add this feature and that will solve it.” When looking at designers portfolios you see variations of, ‘Hey, look what I added!’ Where are the case studies demonstrating such a deep understanding that the designer dared to remove?
  • Ever seen a case study talk about removing bloat? Please share it with me!
• This study by HBR tasked users to create a symmetrical pattern from a grid. A simple solution exists to remove 4 squares that are pre-checked, however, 80% of people went on to fill up 12 more squares to reach symmetry.

Systems are hard to understand

• We observe an event and react to it without real knowledge of the system.
  • Economists and politicians are great at doing this. Quantitative easing is a clear example. Trading some mild relief today for ruin later.
  • Medicine has a term for harm caused by the healer, ‘Iatrogenic,’ (of a disease or symptoms) induced in a patient by the treatment or comments of a physician. Often caused by misinterpretation of the data (doing something before really knowing what is happening).
  • In the best-case scenario, we are cognizant of the complexity. Enter Christopher Alexander on designing a bird table in a garden “I slowly learn that blackbirds have a million subtle forces guiding their behavior. If I don’t understand these forces, there is simply nothing I can do to make the table come to life”.

If interventions work, we get praised

• We praise the football manager who made a substitution in the 87th minute when his team score a last-minute winner. What we do not praise is the manager who exercised restraint when contemplating a substitution but realised his team were playing well they had just not made the breakthrough yet. The decision we did not see is hard to evaluate.
• We tend to view with a certain leniency the actions of someone who, despite having intervened with good intentions, inadvertently causes an undesirable outcome. We often commend their proactive attitude, exclaiming, “At least she was inclined to take action!”

Questions

• this post is intentionally trying to over-index the contrarian view of removal and inaction. Action and intervention are not default bad. How do we develop our Fingerspitzengefühl (fingertip feel) to know when to consider action or inaction?
• this post by Nathan Baschez explains how simple software is created to solve a defined problem. This software then builds more stuff because the current cohort of users asks for it. The software becomes complex and bloated. The company is then disrupted by a simpler new start. How can we avoid this pattern?
• to learn we often have to do something. How can we design lean and meaningful experiments to further de-risk our interventions (Microsoft research suggests only 30% of experiments have a positive impact)?
• the design thinking ideation tool called SCAMPER does reserve a slot for elimination, although I seldom see this technique utilized. How might we bring it into regular discussions?
• how might we reduce the action bias and begin to value the intentional choice of inaction?
• today’s problems are often caused by yesterday’s solutions. How might we engage in meaningful discussion around second-order consequences upfront rather than later when costs (and harm) have already accumulated?

References

1. https://en.wikipedia.org/wiki/Antifragile_(book)
2. https://itamargilad.com/feature-factory/
3. https://every.to/divinations/complexity-convection-765851
4. https://hbr.org/2022/02/when-subtraction-adds-value
5. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4923397/
6. https://evansamek.substack.com/
7. https://www.eferro.net/2021/02/basal-cost-of-software.html
8. https://hdsr.mitpress.mit.edu/pub/aj31wj81/release/1