Home > Java > A profession specific vocabulary built by metaphors

A profession specific vocabulary built by metaphors

When a physician diagnose a patient with a certain condition, that condition has a formally defined name. The Latin words used to describe a medical condition is unfeasible to understand for most people (and I suspect physicians is quite happy with that), but the physician’s colleagues will quickly understand. The reason is of course that they share the same vocabulary. The need to be able to communicate effectively is perhaps the biggest motivation for creating a such profession specific vocabulary, but it also comes in handy when building profession culture. Your own tribal language makes you look cool.

Information technology has of course also developed a profession specific vocabulary. We don’t have a formal language to describe conditions in the same manner as physicians, and problems and their proposed solutions are, with the exception of design patterns, seldom formalized. Instead we enjoy to use cool buzzwords and even cooler metaphors to describe them. Perhaps not very surprising – taking into account the abstract nature of the the product we deliver. A program doesn’t have any physical weight (unless printed, that is!) . Yet, we talk about lightweight (as opposed to heavyweight) frameworks. A program is also of course odorless, yet we talk about code smell. Because we work almost entirely with abstractions, metaphors is of great use when it comes to talk (or write) about them. Our metaphors serves the same purpose to us as Latin definitions does to physicians – when everyone in your tribe knows what the Latin definition/metaphor means, we can communicate and work more effectively. Plus, it makes us look cool.

Golden hammers and silver bullets

I have noted some amusing challenges with our metaphors, however. The first comes to play is when there exists two almost identical metaphors that describe almost the same problem. For example, we talk about golden hammers and silver bullets, two metaphors that are frequently used to describe the same scenario: There is a problem. Do we have already have a technology/tool that we know and love, and looks pretty suitable to solved this problem? Or what about this new, cool technology/tool that probably can solve all such problems? The latter question maps to the silver bullet metaphor. It’s used to describe the expectation of a technology/tool to solve all problems related to a long, prevailing problem domain. The first question maps to the golden hammer metaphor – it’s used to the describe the overuse of an already known technology/tool to solve problems the tool was not designed to solve. Or quoting Abraham Harold Maslow from his book The Psychology of Science: “When the only tool you have is a hammer, it is tempting to treat everything as if it were a nail”. The difference between the two is not hard to spot when compared this way, but in real life, these metaphors are often mixed together. I even heard about a silver hammer once.

Technical debt interpretation 1

The other challenge becomes apparent when one metaphor describes two different things. A famous metaphor is developed by Ward Cunningham and called “Technical debt”. When talking about technical debt, most people talk about the cost associated with choosing a quick and dirty solution over a cleaner one. In my current project, for example, something must frequently be added to, or fixed in the application. Let’s say there are two ways to do it: The first lets us solve the problem quick, but we must cut some corners here and there. The second results in a better, cleaner design, but takes a bit longer. Which one to choose?

Of course, the latter is the better way, but in real life, it all depends. The first way is for instance reasonable if our team is struggling to meet an important deadline. However, quick and dirty comes with a price called technical debt. It’s like borrowing money – there are interests attached to it. The longer we wait before we pay our debt, the more effort is required because we must pay interest. In the technical debt metaphor, the effort grows over time because the quick and dirty design choice makes further changes harder, and until we take the cost of refactoring (and pay that debt), we will continue to pay interest.

When the debt increases, the velocity of the team will decrease until we’ll be using most of our time paying interests, instead of developing that new, cool functionality. The problem is not to raise technical debt – as there are situations where it is sensible to borrow money, there are situations where it is sensible to cut corners as well. The problem is to ignore what we are doing.

Technical debt interpretation 2

However, this interpretation of the technical debt metaphor was not exactly what Ward Cunningham intended, as he explains in the YouTube video – he never meant that technical debt occurs as a consequence of choosing quick and dirty. Not to worry too much, even Martin Fowler seems to have misinterpreted it to some extent 😉

What I interpret as Ward Cunningham’s intention behind the technical debt metaphor, is this: Technical debt increase over time quite naturally if not frequently refactored. The premise is that our code model something, and that something will change over time. If the code is not adapted accordingly to the changes, the code will diverge from the problem domain and fail to meet the (now changed) requirements. As a consequence, the fact that the code once modeled the problem domain perfectly doesn’t mean it can’t get you into some serious technical debt over time. As Fredrik Kalseth notes in his excellent blog, paying back technical debt is really about keeping your code clean.

Note that the first interpretations of the debt metaphor is only a simplification of the latter. Choosing quick and dirty will certainly get you into technical debt, but so will clean code that isn’t refactored to align with its requirements over time. Despite what the technical debt metaphor was originally intended to depict, interpretation variations such as these makes the information technology specific vocabulary both confusing and amusing at the same time!

Metaphors are all around

Metaphors are not as accurate as Latin, but they are probably more fun. And, as Lakoff and Johnson suggest in their famous book “Metaphors we live by”, metaphors are present everywhere, giving structure to our perception and understanding. I haven’t read the whole book, but the first four chapters can be found here. Good reading, highly recommended!

  1. August 10, 2009 at 12:20

    Excellent blog – I seen the metaphor used before, but this blog gives some great links to the source of technical dept.

    Really useful to understand that you should not take up “technical dept” by writing crappy code, and then believe that you could fix it later…!

  2. November 24, 2009 at 12:30

    I really enjoyed reading your blogpost, keep on creating such interesting stuff!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: