Mycobacterium tuberculosis, Immunity, and Software Engineering

Posted on 2025-9-2

software engineeringcomplexitytuberculosisimmune systemsystems

A system is never the sum of its parts its the product of their interaction.

Russel Ackoff

Tuberculosis (TB), also known as the “white death”, sucks. It is a nasty afflication that should have been eradicated decades ago. Unfortunately, due to systemic uneqity that we won’t get into right now, it has killed millions and left even more suffering.

There is nothing positive that can come from TB. Let’s attempt to tranfer learnings from this context to Software Engineering.

For context, I see systems thinking as the essential aspect for any kind of problem solving. Problem solvers of all kinds should pay special attention to, and respect, the system they are working in. The rest of the post will focus on Software Engineering.

Developers of software can learn a lot from how the body puts up a fight again this fatal invasion. While the body’s immune system has to contend with a slipery, aggressive, and cunning mycobacterium, the software engineer has to deal with complexity.

Our entire job hinges on the ability manage complexity effectively. Attempts have given rise to numerous best practices, programming paradigms, flame wars, guidelines and tools. In many cases, each of these attempts has brought its own set of challenges, and often increases the complexity in one way or another.

The equation

The complexity of a program is proportional to the sum of the product of the complexity of each sub-program and how much time needs to be alloted to it.

complexity=∑p(cp∗tp)complexity = \sum_p (cp * tp)

The complexity of the whole program depends on how complex its components are and how much time you need to spend on each component. If a program has a very complex component, but you never have to spend any time on it, that component essentially has no complexity at all. This “elimination” of complexity at the sub-program level compounds and makes the overall program less complex.

This is so important, we are going to re-write it.

Say there exists an island with dangerous dragons capable of laying waste to you and your town. This is no good. BUT, if there is no way for the dragons to ever make contact with your town, the seriousness of the condition is drastically reduced. Now you can choose when to journey to the island to tame the danger, on your terms.

Managing complexity well eases the other symptoms of working in complex systems, namely (as per John Ousterhout):

  1. Change amplification - a simple change requires modifications in many different places
  2. Cognitive load - how much you need to know in order to complete a task
  3. Unknown unknonws - it is not obvious which pieces must be known to complete a task

The tuberculosis of it all

The body does a very similar thing when dealing with an infection it cannot fight - in this case Tuberculosis. Due to the futility of fighting the mycobacterium tuberculosis pathogens head on, large numbers immune cells surround the invadors and form a hard shell that effectively contains the infection to one location.

This “walling off”, is essential to the continued functioning of the lungs. Incase you needed a reminder, lungs are very important to the overall human experience (life).

Note: The body is a complex system, often times the body fails to wall off the infection (malnutrition, co-morbidities, compromised immune system) and the infection spreads and slowly consumes the patient. Another name for Tuberculosis was “the consumption” for this very reason.

What now

To reduce the complexity of a piece of software (or any solution with interacting parts), we should identify the sources of complexity and isolate/contain them in walled off sections (modules).

This effectively:

  1. Reduces the number of interactions between parts. All things closely related to the complex item are also contained together with it (see modules should be deep).
  2. Reduces cognitive load. Developers don’t need to keep the complex modules in mind - or even understand what they do and how - to make use of them and their results
  3. Reduces unknown unknowns - by replacing them with known unknowns.

Modules containing the complexity confine it such that we rarely have to look inside them, if ever - drastically reducing the impact of their complexity on the team and the larger program.

References:

Categoric•ally

Categoric•ally