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.