Applying metaphors from other fields into software development - codeutopia.net

Applying metaphors from other fields into software development

Posted on May 23, 2026

Tags: programming

We use all kinds of metaphors in programming. Using “code smell” to describe poor coding practices is probably one of the most evocative. But what about metaphors in other fields? Could they be used to describe programming as well?

There are a lot of things like “parent” and “child”, or “building” or “factory”, which clearly originate elsewhere. But these are quite widely used already in programming to the point that we don’t necessarily even think of them as metaphors anymore… So what I’m interested in is stuff that’s less common, or perhaps entirely unused in software development circles.

Why metaphors? I think “code smell” is actually a great example - surely you don’t want your codebase to be icky and stinky? You immediately get a sense of how it’s something you don’t want, without having to iterate through the details. They are also great for helping you think of something from a new perspective, giving you new ideas, or grounding a more abstract concept in something tangible. There is also some research suggesting metaphors can help with learning.

Let’s take a look at a few, which I think are interesting, but are more common in other fields instead of software development.

A Metaphor(a)

The Flywheel Effect

The Flywheel Effect metaphor originates from the business management book Good to Great. The flywheel effect compares business decisions to spinning up a flywheel, where each small decision makes the flywheel spin faster, eventually leading to a bigger breakthrough. I’ve not read the book so I can’t comment its accuracy, but I think it’s a metaphor we could use to describe software development processes as well.

For example, you could picture the aforementioned code smells as actions that affect the flywheel. The more code smells you have, the faster the wheel spins. The faster the wheel spins, the harder it is to stop. To put it in another way, the more Technical Debt you acquire, the higher its impact is to the overall development effort. The more debt you have, the harder it’s to get rid of it. If you imagine a fast spinning flywheel, you don’t even want to go near it much less touch it, very much a feeling I get from technical debt sometimes.

You could also think of it from the perspective of learning programming languages and libraries. The more of them you know, the faster it will be to pick up new ones, which could be seen as spinning up a flywheel.

Entropy

Entropy is a concept from physics. Somewhat simplified, one way to explain it is that disorder tends to increase over time, and to reduce disorder you need to spend energy.

In context of software development, entropy could be said to increase as the system gets increasingly complex. In order to combat entropy, we need to spend energy - efforts to reduce technical debt, do refactorings, and other measures. I originally saw this metaphor described in context of software architecture in the book Fundamentals of Software Architecture.

This seems like a very apt metaphor for how we need to spend an increasing amount of time on “tidying up” as projects get bigger. Plus, it’s interesting how it ties programming to such a fundamental aspect of physics.

The Compound Effect

The Compound Effect metaphor in this case is from the motivational/self-help book The Compound Effect. The idea is that each small choice you make every day compounds, allowing you to reach much larger goals.

The idea behind this metaphor is fairly similar to the flywheel effect, but it may appeal more to more analytical or mathematically minded people, since compounding is more math-related as a concept. You could also look at it from the investment perspective, as compound interest is similar.

If we look at it in context of programming, it’s easy to see it from the investment perspective. For example, if we invest time into good practices, Unit Tests, etc. now, we will reap bigger benefits later. We could also look at it from the “small choices” perspective, where small improvements we do to the codebase now help us build towards compounding larger improvements later.

I think for a lot of investors, compound interest only starts to really matter after decades. I would hope that we can see the compound effect faster in software.

The Broken Windows theory

The Broken Windows Theory is an idea from Criminology. It’s not really a metaphor by itself, but if we take the idea and apply it to programming it becomes one, since we don’t have literal buildings or windows in software.

The gist of the broken windows theory is that if a building has a broken window, the rest will be broken soon as well. This is then expanded to suggest that this kind of urban decay encourages crime - the more broken windows, the more crime. This theory has had a lot of criticism towards it, but the...