0:00:00.000,0:00:01.522
Metaphor

0:00:03.862,0:00:07.834
I became interested in the way metaphors

0:00:07.834,0:00:10.427
influence how we think

0:00:10.427,0:00:13.508
after reading George Lakoff and Mark Johnson's

0:00:13.508,0:00:15.148
"Metaphors We Live By".

0:00:15.298,0:00:17.822
An important idea is that

0:00:17.822,0:00:23.644
we reason by analogy with the metaphors

0:00:23.644,0:00:25.688
that have entered our language.

0:00:26.358,0:00:27.976
Debt

0:00:29.736,0:00:33.510
I coined the debt metaphor to explain

0:00:33.510,0:00:35.592
the refactoring that we were doing

0:00:35.592,0:00:38.733
on the WyCash product.

0:00:38.733,0:00:41.874
This was an early product

0:00:41.874,0:00:45.017
done in Digitalk Smalltalk

0:00:45.017,0:00:47.647
and it was important to me that

0:00:47.647,0:00:50.316
we accumulate the learnings we did

0:00:50.316,0:00:52.396
about the application over time

0:00:52.396,0:00:57.236
by modifying the program to look

0:00:57.236,0:01:00.517
as if we have known what we were doing

0:01:00.517,0:01:03.956
all along and to look as if it had been easy

0:01:03.956,0:01:06.583
to do in Smalltalk.

0:01:06.583,0:01:09.010
The explanation I gave to my boss,

0:01:09.010,0:01:11.059
and this was financial software,

0:01:11.059,0:01:15.268
was a financial analogy I called "the debt metaphor".

0:01:15.268,0:01:19.213
And that said that if we failed to make our

0:01:19.213,0:01:22.558
program align to what we then understood

0:01:22.558,0:01:25.875
to be the proper way to think about our

0:01:25.875,0:01:28.607
financial objects, then we were going to

0:01:28.607,0:01:31.686
continually stumble over that disagreement

0:01:31.686,0:01:34.383
and that would slow us down which was like

0:01:34.383,0:01:36.506
paying interests on a loan.

0:01:37.016,0:01:38.842
Speed

0:01:39.878,0:01:42.495
With borrowed money you can

0:01:42.495,0:01:45.062
do something sooner than you might otherwise

0:01:45.062,0:01:47.958
but then until you pay back that money

0:01:47.958,0:01:50.757
you will be paying interest.

0:01:52.197,0:01:55.791
I thought borrowing money was a good idea

0:01:55.791,0:01:58.896
I thought that rushing software out the door

0:01:58.896,0:02:01.937
to get some experience with it was a good idea

0:02:01.937,0:02:06.996
but that of course you would eventually go back

0:02:06.996,0:02:09.158
and as you learned things about that software

0:02:09.158,0:02:11.987
you would repay that loan

0:02:11.987,0:02:15.516
by refactoring the program

0:02:15.516,0:02:19.686
to reflect your experience as you acquired it.

0:02:20.246,0:02:21.998
Burden

0:02:22.808,0:02:24.920
I think that there were plenty of cases

0:02:24.920,0:02:28.948
where people would rush software out the door

0:02:28.948,0:02:32.241
and learn things but never put that

0:02:32.241,0:02:34.508
learning back into the program

0:02:34.508,0:02:39.482
and that by analogy was borrowing money

0:02:39.482,0:02:42.711
thinking that you never had to pay it back.

0:02:42.711,0:02:45.550
Of course, if you do that, say with your

0:02:45.550,0:02:48.061
credit card, eventually all your income

0:02:48.061,0:02:50.348
goes to interest and your purchasing power

0:02:50.348,0:02:53.336
goes to zero. By the same token, if you

0:02:53.336,0:02:55.956
develop a program for a long period of time

0:02:55.956,0:02:57.704
by only adding features

0:02:57.704,0:03:00.367
and never reorganizing it to reflect

0:03:00.367,0:03:02.593
your understanding of those features

0:03:02.593,0:03:04.741
then eventually that program simply

0:03:04.741,0:03:07.130
does not contain any understanding

0:03:07.130,0:03:08.927
and all efforts to work on it

0:03:08.927,0:03:11.163
take longer and longer.

0:03:11.163,0:03:14.292
In other words, the interest is total,

0:03:14.292,0:03:15.929
you make zero progress.

0:03:16.349,0:03:18.141
Agility

0:03:19.231,0:03:23.317
A lot of bloggers at least have explained

0:03:23.317,0:03:26.830
the debt metaphor and confused it, I think,

0:03:26.830,0:03:31.188
with the idea that you could write code poorly

0:03:31.188,0:03:33.860
with the intention of doing a good job later

0:03:33.860,0:03:35.315
and thinking that

0:03:35.315,0:03:38.500
that was the primary source of debt.

0:03:38.500,0:03:41.735
I am never in favor of writing code poorly

0:03:41.735,0:03:45.732
but I am in favor of writing code to reflect

0:03:45.732,0:03:47.585
your current understanding of a problem

0:03:47.585,0:03:49.948
even if that understanding is partial.

0:03:49.948,0:03:53.980
If you want to be able to go into

0:03:53.980,0:03:57.330
debt that way by developing software

0:03:57.330,0:03:59.115
that you do not completely understand,

0:03:59.115,0:04:02.950
you are wise to make that software reflect

0:04:02.950,0:04:05.154
your understanding as best as you can

0:04:05.154,0:04:08.277
so that when it does come time to refactor

0:04:08.277,0:04:09.596
it is clear what you were thinking

0:04:09.596,0:04:11.333
when you wrote it,

0:04:11.333,0:04:13.949
making it easier to refactor it

0:04:13.949,0:04:16.114
into what your current thinking is now.

0:04:16.114,0:04:18.503
In other words, the whole debt metaphor,

0:04:18.503,0:04:21.218
let's say, the ability to pay back debt,

0:04:21.218,0:04:23.738
and make the debt metaphor work for your

0:04:23.738,0:04:26.031
advantage depends upon your writing

0:04:26.031,0:04:29.018
code that is clean enough to be able to refactor

0:04:29.018,0:04:31.569
as you come to understand your problem.

0:04:31.569,0:04:34.330
I think that is a good methodology.

0:04:34.330,0:04:36.969
It is at the heart of Extreme Programming.

0:04:36.969,0:04:39.618
The debt metaphor is an explanation,

0:04:39.618,0:04:41.609
one of many explanations for why

0:04:41.609,0:04:43.638
Extreme Programming works.