WEBVTT 00:00:00.000 --> 00:00:01.522 Metaphor 00:00:03.862 --> 00:00:07.834 I became interested in the way metaphors 00:00:07.834 --> 00:00:10.427 influence how we think 00:00:10.427 --> 00:00:13.508 after reading George Lakoff and Mark Johnson's 00:00:13.508 --> 00:00:15.148 "Metaphors We Live By". 00:00:15.298 --> 00:00:17.822 An important idea is that 00:00:17.822 --> 00:00:23.644 we reason by analogy with the metaphors 00:00:23.644 --> 00:00:25.688 that have entered our language. 00:00:26.358 --> 00:00:27.976 Debt 00:00:29.736 --> 00:00:33.510 I coined the debt metaphor to explain 00:00:33.510 --> 00:00:35.592 the refactoring that we were doing 00:00:35.592 --> 00:00:38.733 on the WyCash product. 00:00:38.733 --> 00:00:41.874 This was an early product 00:00:41.874 --> 00:00:45.017 done in Digitalk Smalltalk 00:00:45.017 --> 00:00:47.647 and it was important to me that 00:00:47.647 --> 00:00:50.316 we accumulate the learnings we did 00:00:50.316 --> 00:00:52.396 about the application over time 00:00:52.396 --> 00:00:57.236 by modifying the program to look 00:00:57.236 --> 00:01:00.517 as if we have known what we were doing 00:01:00.517 --> 00:01:03.956 all along and to look as if it had been easy 00:01:03.956 --> 00:01:06.583 to do in Smalltalk. 00:01:06.583 --> 00:01:09.010 The explanation I gave to my boss, 00:01:09.010 --> 00:01:11.059 and this was financial software, 00:01:11.059 --> 00:01:15.268 was a financial analogy I called "the debt metaphor". 00:01:15.268 --> 00:01:19.213 And that said that if we failed to make our 00:01:19.213 --> 00:01:22.558 program align to what we then understood 00:01:22.558 --> 00:01:25.875 to be the proper way to think about our 00:01:25.875 --> 00:01:28.607 financial objects, then we were going to 00:01:28.607 --> 00:01:31.686 continually stumble over that disagreement 00:01:31.686 --> 00:01:34.383 and that would slow us down which was like 00:01:34.383 --> 00:01:36.506 paying interests on a loan. 00:01:37.016 --> 00:01:38.842 Speed 00:01:39.878 --> 00:01:42.495 With borrowed money you can 00:01:42.495 --> 00:01:45.062 do something sooner than you might otherwise 00:01:45.062 --> 00:01:47.958 but then until you pay back that money 00:01:47.958 --> 00:01:50.757 you will be paying interest. 00:01:52.197 --> 00:01:55.791 I thought borrowing money was a good idea 00:01:55.791 --> 00:01:58.896 I thought that rushing software out the door 00:01:58.896 --> 00:02:01.937 to get some experience with it was a good idea 00:02:01.937 --> 00:02:06.996 but that of course you would eventually go back 00:02:06.996 --> 00:02:09.158 and as you learned things about that software 00:02:09.158 --> 00:02:11.987 you would repay that loan 00:02:11.987 --> 00:02:15.516 by refactoring the program 00:02:15.516 --> 00:02:19.686 to reflect your experience as you acquired it. 00:02:20.246 --> 00:02:21.998 Burden 00:02:22.808 --> 00:02:24.920 I think that there were plenty of cases 00:02:24.920 --> 00:02:28.948 where people would rush software out the door 00:02:28.948 --> 00:02:32.241 and learn things but never put that 00:02:32.241 --> 00:02:34.508 learning back into the program 00:02:34.508 --> 00:02:39.482 and that by analogy was borrowing money 00:02:39.482 --> 00:02:42.711 thinking that you never had to pay it back. 00:02:42.711 --> 00:02:45.550 Of course, if you do that, say with your 00:02:45.550 --> 00:02:48.061 credit card, eventually all your income 00:02:48.061 --> 00:02:50.348 goes to interest and your purchasing power 00:02:50.348 --> 00:02:53.336 goes to zero. By the same token, if you 00:02:53.336 --> 00:02:55.956 develop a program for a long period of time 00:02:55.956 --> 00:02:57.704 by only adding features 00:02:57.704 --> 00:03:00.367 and never reorganizing it to reflect 00:03:00.367 --> 00:03:02.593 your understanding of those features 00:03:02.593 --> 00:03:04.741 then eventually that program simply 00:03:04.741 --> 00:03:07.130 does not contain any understanding 00:03:07.130 --> 00:03:08.927 and all efforts to work on it 00:03:08.927 --> 00:03:11.163 take longer and longer. 00:03:11.163 --> 00:03:14.292 In other words, the interest is total, 00:03:14.292 --> 00:03:15.929 you make zero progress. 00:03:16.349 --> 00:03:18.141 Agility 00:03:19.231 --> 00:03:23.317 A lot of bloggers at least have explained 00:03:23.317 --> 00:03:26.830 the debt metaphor and confused it, I think, 00:03:26.830 --> 00:03:31.188 with the idea that you could write code poorly 00:03:31.188 --> 00:03:33.860 with the intention of doing a good job later 00:03:33.860 --> 00:03:35.315 and thinking that 00:03:35.315 --> 00:03:38.500 that was the primary source of debt. 00:03:38.500 --> 00:03:41.735 I am never in favor of writing code poorly 00:03:41.735 --> 00:03:45.732 but I am in favor of writing code to reflect 00:03:45.732 --> 00:03:47.585 your current understanding of a problem 00:03:47.585 --> 00:03:49.948 even if that understanding is partial. 00:03:49.948 --> 00:03:53.980 If you want to be able to go into 00:03:53.980 --> 00:03:57.330 debt that way by developing software 00:03:57.330 --> 00:03:59.115 that you do not completely understand, 00:03:59.115 --> 00:04:02.950 you are wise to make that software reflect 00:04:02.950 --> 00:04:05.154 your understanding as best as you can 00:04:05.154 --> 00:04:08.277 so that when it does come time to refactor 00:04:08.277 --> 00:04:09.596 it is clear what you were thinking 00:04:09.596 --> 00:04:11.333 when you wrote it, 00:04:11.333 --> 00:04:13.949 making it easier to refactor it 00:04:13.949 --> 00:04:16.114 into what your current thinking is now. 00:04:16.114 --> 00:04:18.503 In other words, the whole debt metaphor, 00:04:18.503 --> 00:04:21.218 let's say, the ability to pay back debt, 00:04:21.218 --> 00:04:23.738 and make the debt metaphor work for your 00:04:23.738 --> 00:04:26.031 advantage depends upon your writing 00:04:26.031 --> 00:04:29.018 code that is clean enough to be able to refactor 00:04:29.018 --> 00:04:31.569 as you come to understand your problem. 00:04:31.569 --> 00:04:34.330 I think that is a good methodology. 00:04:34.330 --> 00:04:36.969 It is at the heart of Extreme Programming. 00:04:36.969 --> 00:04:39.618 The debt metaphor is an explanation, 00:04:39.618 --> 00:04:41.609 one of many explanations for why 00:04:41.609 --> 00:04:43.638 Extreme Programming works.