Applying metaphors from other fields into software development

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.

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 image of a building with broken windows is quite powerful and we can use it in context of programming.

This is going to be another example relating to good code / bad code. For some reason all of these are about that. In any case: When you’re working in a codebase with a lot of technical debt and which is, to put it bluntly, kind of crap, you’re a lot more likely to write code that just does the job and doesn’t really improve things. You might want to improve the situation, but often when the code is kinda crap, it would take a lot of effort, time or frustration to fix it, and at that point at least I don’t always feel like it.

On the opposite side, if you have a really nice and clean codebase, you would be less likely to want to make it worse, and you’d try to keep it nice and tidy. So in this sense, when your code has a lot of “broken windows”, more of them are going to keep breaking.

Interestingly enough, there is some research that supports this interpretation of the theory. The paper The Broken Windows Theory Applies to Technical Debt studies whether a codebase containing technical debt makes a developer more likely to contribute more debt to it or not, in comparison to a codebase with less technical debt. The result of the study shows developers are more likely to create further technical debt, even when it’s unnecessary to do so, if a codebase is already debt-ridden.

What makes metaphors are interesting and useful

I find connecting other fields to programming particularly interesting, because sometimes another field has an insight that we might not. This can lead to new ideas which then improve our field - good examples of this are kanban and agile methods, which originate from or are influenced by the manufacturing industry.

Other really common and important metaphors used in software are Technical Debt and Design Patterns. Much conversation and development work is around technical debt, its impacts and preventing it. I think technical debt is a great metaphor partially because it’s a good communication tool: Even a non-technical manager understands what debt is, and that it probably has to be repaid. As an aside, it seems the meaning of technical debt has somewhat diverged from what it originally meant.

The metaphors used in Design Patterns are great for similar reasons, as they make communicating the concepts they represent straightforward. For example, if I say “You can use the Command pattern for undo/redo”, it immediately gives you ideas if you’re familiar with the pattern. Compare having to explain “You can use a class which represents an action and provides a way to execute or reverse it…”… it’s kinda wordy. The origin of Design Patterns is also in a non-programming field. It’s based on ideas presented in the book A Pattern Language, which discusses urban design. I’ve been meaning to read it sometime, but haven’t gotten around to it yet.

When a metaphor is very evocative, I’ve found it can help foster new ideas about the concept. The flywheel effect in particular is something I find easy to imagine, how it gains more momentum when you do (or don’t do) certain actions. And yet, this metaphor is the only one in my list that I could not find any examples of in context of programming from anyone else.

Do you know of any other interesting metaphors from non-programming fields that could be used to describe software development? I’d be very curious to hear.