Debt Metaphor

Ward Cunningham reflects on the history, motivation and common misunderstanding of the "debt metaphor" as motivation for refactoring.

Metaphor

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.

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 have 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 to 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 was like

paying interests 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 will 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, 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 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 am 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.

If you want to be able to go into

debt that way by developing software

that you do not 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 is 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 is a good methodology.

It is at the heart of Extreme Programming.

The debt metaphor is an explanation,

one of many explanations for why

Extreme Programming works.