Ward Explains Debt Metaphor

WardCunningham posted a video explaining Debt Metaphor (see TechnicalDebt, for example) himself, clearing some confusion in the blogosphere about it.

The transcript of the video is below.

(Thank you, Ward. We are indebted to you for your inspirational words)

Contributors: JuneKim, LawrenceWang

Metaphor

I became interested in the way metaphors influence how we think after reading George Lakoff and Mark Johnson's MetaphorsWeLiveBy. An important idea is that we reason by analogy with the metaphors that have entered our language.

Debt

I coined the debt metaphor to explain the refactoring that we were doing on the WyCash product. This was an early product done in Digitalk Smalltalk, and it was important to me that we accumulate the learnings we did about the application over time by modifying the program to look as if we had known what we were doing all along and to look as if it had been easy to do in Smalltalk.

The explanation I gave to my boss, and this was financial software, was a financial analogy I called "the debt metaphor". And that said that if we failed to make our program align with what we then understood to be the proper way to think about our financial objects, then we were gonna continually stumble over that disagreement and that would slow us down which was like paying interest on a loan.

Speed

With borrowed money you can do something sooner than you might otherwise, but then until you pay back that money you'll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

Burden

I think that there were plenty of cases where people would rush software out the door and learn things but never put that learning back into the program, and that by analogy was borrowing money thinking that you never had to pay it back.

Of course, if you do that, you know, say with your credit card, eventually all your income goes to interest and your purchasing power goes to zero.

By the same token, if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer. In other words, the interest is total -- you'll make zero progress.

Agility

A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt.

I'm never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.

You know, if you want to be able to go into debt that way by developing software that you don't completely understand, you are wise to make that software reflect your understanding as best as you can, so that when it does come time to refactor, it's clear what you were thinking when you wrote it, making it easier to refactor it into what your current thinking is now.

In other words, the whole debt metaphor, let's say, the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem.

I think that's a good methodology. It's at the heart of Extreme Programming. The debt metaphor is an explanation, one of many explanations why Extreme Programming works.

You are free to copy, distribute, transmit and adapt these words from the video under the terms of the Creative Commons Attribution 3.0 license. http://creativecommons.org/licenses/by/3.0/ It is sufficient to attribute authorship to "Ward Cunningham" though a link to this page is always appreciated. -- WardCunningham