Monday, August 26, 2013

Not All Debts Are Equal (Part 1)

This is the first of a series of posts that I will be making in preparation for a panel discussion on Technical Debt at SPLASH 2013 which will held in Indianapolis, Indiana from October 26-31, 2013. 

Does having different interpretations of the Technical Debt metaphor mean that it suffers from semantic diffusion or does it simply provide evidence of its linguistic evolution and not necessarily its diminished usefulness? In this series of posts, I will explore the different things that Technical Debt has come to mean throughout the industry and whether these different meanings make the metaphor more or less useful.

"You keep using that word. I don't think it means what you think it means." -- Inigo Montoya, The Princess Bride

+Martin Fowler coined the phrase "Semantic Diffusion" to describe how the meaning of a word or phrase can weaken as its use spreads through the wider community.  For example, the terms "agile" and "refactoring" have arguably suffered from semantic diffusion over the years as people use them in different contexts and apply them to things for which they were perhaps not meant to apply.

Fowler posits that semantic diffusion is more likely to occur with things that are broad concepts rather than hard technologies.  Technical Debt seems to be one such broad concept whose meaning has been morphed and applied to a wider range of circumstances than was originally intended.

A Quick Confession

I have to admit that prior to this writing, I had an entirely different idea of what constituted technical debt. I thought that technical debt was anything that slowed you down: messy code, poor designs, misunderstood or missing requirements, lack of security, poor performance, and pretty much any other technical issue.

I'm not really sure how or why I had settled on this divergent and arguably incorrect definition of technical debt.  I can only speculate that it stemmed partly from my lack of insight into the original meaning--Ok, I admit I was too lazy to look into it in depth--but more likely from a healthy dose of "assume" (we know what happens when you do that) and a generous coating of personal bias from past experiences of being hampered by technical issues.

I do know for sure that I'm not the only one who had this view of technical debt.  Note that I wrote "had this view." I'll explain more about that later.

First, let's establish a baseline understanding of the term as originally proposed by +Ward Cunningham. It's important to understand the original meaning so we have a basis for comparing other, perhaps divergent, meanings.

Ward Cunningham's Debt Metaphor

Ward mentioned the debt metaphor in a 1992 OOPSLA experience report.  He also explains the debt metaphor in a YouTube video and a transcription of it can be found on Ward's wiki.  He relates how he coined the term as a way to explain the refactoring being done on the WyCash financial product he was working on at the time. It stands to reason that he would choose a financial concept to explain the technical choices they made while developing a financial product.  Had the product been of a different nature, we might have ended up with a different metaphor altogether but as chance would have it, Ward chose debt. The rest, as they say, is history.

Let's take a closer look at what Ward says in the video and try to identify different analogies that we can derive from the debt metaphor.

Analogy #1: Reaping a benefit sooner

Ward says, "With borrowed money, you could do something sooner than you might otherwise."

Let me add a little bit of nuance to that.  Borrowing money allows you to benefit much sooner than it would be possible without money. With borrowed money, you can buy a car or a house, go on vacation, or start a business. Likewise, charging purchases to a credit card allows you to avail of goods and services well in advance of actually paying money for them. Presumably, having or doing these things is beneficial to you. Therefore, borrowing is a way for you to reap a benefit sooner rather than later.

Ward compares borrowing money to rushing software out the door before it reflects a full understanding of the system. Doing this allows you to get some experience with the program and learn more about it sooner. It's interesting to note that it really doesn't matter that the software is still conceptually incomplete or that the problem is not completely understood. You're not really concerned with that at this point. You're only interested in the opportunity to use what you currently have to explore and learn more about what should be the correct and complete solution.  When this is the case, you benefit by going into technical debt as a way to gain experience and understanding sooner.

This leads to the first analogy of the debt metaphor:
Getting working software out the door so you can get some experience with it sooner is like borrowing money so you can reap some benefit sooner.
This kind of reminds me of a quine, a program with no input but whose output is the source code of the program itself.  There's a hint of this recursive nature when you use a program to help you make improvements to the program itself. It's also reminiscent of the saying "You need money to make money" but in this case it becomes "You need working software to make working software."

Analogy #2: Assuming an obligation to pay

When you borrow money, you assume the obligation and responsibility to pay someone back. When you take out a loan, you have to pay the lender back. When you charge purchases to a credit card, you're obligated to pay the credit card company.

But what is the currency of technical debt and what obligation and responsibility comes with borrowing it?

Time is the currency of technical debt. Specifically, you are borrowing time with which to use working software so that, as already noted, you can learn and understand more about the problem and the solution. The obligation that comes with borrowing time is the same that comes with borrowing money:  you must pay it back.

Of paying back borrowed time, Ward says "you would repay that loan by refactoring the program to reflect your experience as you acquired it."  That is, you fulfill your obligation to pay back borrowed time by spending time to refactor and update the program so that it reflects a clearer and more complete understanding of how it should behave.

This is the second analogy of the debt metaphor:
The obligation to make the program reflect what you learned on borrowed time is like the obligation you have to pay back borrowed money.

Analogy #3: Interest Payments

When you assume the obligation to pay back borrowed money, you also assume an obligation to pay back slightly more than the amount that you borrowed.  This, of course, is the interest that you pay on the loan and it represents a cost to you, the borrower.

Ward notes that borrowing money so you can do something sooner is a good idea but "until you pay back that money, you'll be paying interest."

Thus, Ward reasoned that if they "failed to make the program align with what was then understood to be the proper way to think about financial objects," then they would "continually stumble over that disagreement" and this would slow them down.

This again indicates that time is the currency of technical debt.  Getting slowed down is a cost that is measured in terms of the time it takes to get things done. The longer it takes to pay a lender back in full, the more interest you will have pay over time.  Likewise, the longer it takes for you to reflect new learnings into the software, the longer it will take for you to get things done.

This leads us to the third analogy of the original debt metaphor:
Making slower progress because you didn't reflect learnings back into the software is like paying more interest on an outstanding debt.

Analogy #4: Defaulting on a loan

Problems with debt arise when borrowers start defaulting on their loans. When you don't make regular payments on a loan, you can get socked with fees and increased interest rates. The longer you default on your loan, the more trouble you get into. If you stay in default long enough, you'll eventually find yourself in an untenable position where any amount you pay will only be enough to pay down the interest and fees and none of the original amount you borrowed. So instead of owing less, you end up owing more and more over time.

Ward explains the parallels with technical debt this way:
"People rush software out the door but never put learning back into the program. This is like borrowing money thinking that you'd never have to pay it back. If you do that eventually all your income goes to interest and your purchasing power goes to zero. If you develop a program ... and never reorganize it to reflect your understanding... eventually the program does not contain any understanding and all efforts to work on it take longer and longer.  In other words, the interest is total and you'll make zero progress."
In short, the fourth analogy of the debt metaphor is:
Not putting learning back into the program is like defaulting on a loan.
A related analogy is this:
A program that does not contain any understanding is like a loan for which you can only afford to pay the interest. 

So, what exactly is "Technical Debt" then?

After carefully studying Ward's explanation of the metaphor and reading between the lines a bit, I have changed my opinion of what Technical Debt means.  If I understand Ward's original intent, it all boils down to "a lack of understanding of the software."

As a metaphor, I think that it's really more important to view technical debt as something you choose to do rather than as something that you have. That is, thinking in terms of "going into debt" rather than in terms of "having debt" is more useful and I think Ward may have even alluded to this somewhat in his video.

Going into technical debt is not so much a problem as it is a conscious choice and commitment. At least that's the way it should be. Just as borrowing money so you can benefit sooner is a good thing, taking on technical debt so you can benefit from using the software sooner is also a good thing. You just have to be responsible and remember to pay back your debt by refactoring the program to reflect any learning you acquired from using the software sooner. Diligently paying back your debt helps you stay out of trouble and allows you to make the debt metaphor work to your advantage.


In this post, I went over the debt metaphor as originally proposed by +Ward Cunningham. I identified several analogies that can be derived from the metaphor.  I proposed that going into technical debt is really not so much a problem as it is a choice and commitment that you make so you can benefit from using working software to gain more understanding about a problem and the software itself.  It is also important to remember that you have an obligation and responsibility to repay your debt by reflecting any learning you acquire back into the program.


In upcoming posts, I'll continue to explore more nuances of the original debt metaphor and other aspects of the analogies that can be derived from it.  I'll explore the meaning of the phrase "software that does not contain understanding" and point out gaps in the metaphor that can lead to misunderstanding and weakening from semantic diffusion.

Post a Comment