Ward Explains Debt Metaphor

This is a transcript from a video Ward Cunningham recorded in 2009¹

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

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’re 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 fail to make our program align with what we then understood to be the proper way to think about our financial objects then we were going to continually stumble over that disagreement and that would slow us down which is like paying interest on a loan. 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 learn things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

I think that there were plenty of cases where people would rush software out the door and learn things but never, 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 to take longer or longer. In other words the interest is total you’ll make zero progress.

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 was the primary source of debt. I’m never in favor of writing code poorly but I am in favor 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’re wise to make that software reflect your understanding as best you can so that when it does come time to refactor it’s clear what you were thinking when you wrote it and making it easier to refactor it into what your current thinking is now.

In other words the whole debt metaphor or let’s say the ability to pay back debt, and make the debt metaphor work for your advantage, depends upon you 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 of why extreme programming works.

---

WardExplainsDebtMetaphor. 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. (CC BY 3.0)