Are your metaphors leading you astray?
Metaphors and similes are some of the most powerful tools for thinking available to us as software engineers. They allow us to apply intuition we’ve developed in one domain to another. This is particularly helpful in an abstract domain where there’s little in the way of common sense or instinct available.
It’s no surprise then that software engineering as a field is lousy with metaphors and metaphoric language. We talk of debt, factories, crashes, bugs, worms, etc. By and large, these metaphors are beneficial but, by their very nature, metaphors are inexact. I think it’s important to pause sometimes and reflect on what metaphors we’re using and how they’re impacting your thought processes.
The expense of metaphors
To use a metaphor well, you have to climb inside it and spend a bunch of time understanding where it’s a good analogue and where it isn’t. This can be a lot of effort, and often people don’t do it. Instead, they end up lazily applying a metaphor with some shallow appeal and ignoring the bits where it doesn’t apply.
An example of a really terrible simile I’ve come across is telling a software development team in a large enterprise that they should “act like a startup”. The intent here is fairly clear, but unless you’re going to give them significant equity and autonomy in decision-making, this simile is not helpful and could easily just wind up becoming interpreted as code for “be available day and night”.
This isn’t to say that you can’t ask the question, “what would it be like for this team to behave like a startup” and then follow on by finding all the ways this metaphor breaks down. This might actually get you somewhere towards identifying institutional problems that discourage ownership and autonomy.
Another viral metaphor is the idea of “technical debt”. This idea has flaws; for example, that some technical debt winds up never needing to be paid back, but it’s popular and helpful to talk about and understand these flaws. Even just using the metaphor to put a snappy name on some nebulous concepts of software quality is pretty useful.
The takeaway here is that the ways an otherwise good metaphor breaks down are often the really instructive bits! However, understanding all this takes time and energy to do well, so it’s important to limit the number of metaphors you apply at any one time and dive in and interrogate the points of contention on the ones you adopt.
The danger of metaphors
The metaphors we use in software are also a product of the people who wrote a lot of the software and tend to encode their implicit bias. These biases include gender, racial, or other cognitive biases that make the practice of software engineering less inclusive of minority perspective. Proper discussion of this topic warrants a whole piece of its own, so for the moment I just want to mention some classes of metaphors I think we use too heavily and ones we don’t use enough.
Financial metaphors, construction metaphors and physical production metaphors are useful but over-represented, e.g. "debt", "architecture", "shipping" etc. I’m not sure why this is; perhaps the people who write software either like to think of themselves as financial geniuses or burly construction workers? Or maybe it’s just that they sound exciting and smart and are superficially fairly obvious?
Whatever the reason, they’re everywhere, and like all metaphors, they have problems. For example, iterative improvement works amazingly well in software development but is pretty terrible when you’re remodelling your kitchen. As a result, using construction metaphors heavily will likely lead you to underemphasize continuous improvement over upfront design.
Metaphors I don’t see used enough are those that relate to domestic chores or health/exercise. For example you don't often hear people describing how software maintenance is like tending a garden, or tidying your bedroom. Metaphors like these have their own flaws, but they highlight some of the more humdrum, boring, but fundamental aspects of software development. Many of the things we do are akin to brushing your teeth rather than building a spaceship. They’re routine, relatively low stakes but essential to do regularly, or things get out of hand.
With the wrong metaphors in our arsenal, we lose sight of these things entirely. So it’s essential to have some diversity in your metaphors. Clearly, this is in tension with the idea that you should limit the number of metaphors you use to ones you have explored and understood well. As with many things in life, it’s a matter of finding a healthy balance.
Summing up
Metaphors can be very powerful and illuminating but use them sparingly. In particular, focus on where they break down and try to ensure they reflect a diversity of perspectives rather than reinforcing a single viewpoint.