This example teaches two lessons, in my view. First, we are very likely, as time goes on, to see better ways to have done our work. Second, if we keep the design we have as clean as possible, adjusting to those better ways will be easier.

14/22

Now you know, and I know, never to use a float for money. But there is something we don't know now about the next system we build, and someday that thing will be as obvious to us as "NEVER USE FLOATS FOR MONEY" is today.

15/22

So the second lesson -- keep the design as clean as possible -- is critical. With a clean design, design improvements are generally easy. Modularity works. The more messy our existing design, the less likely we are to be able to improve it even after we learn how.

16/22

Unfortunately, today, "technical debt" has often come to mean something like "judiciously skimp on design today, so that we can go faster; we'll clean it up later".

17/22

In my view, there is no useful meaning for "judiciously skimp on design today". Every design flaw we leave in the system today will slow us down tomorrow.

I don't mean "in the future". I mean, literally, tomorrow.

18/22

Our design will inevitably deviate from the best design we can imagine, because we're learning as we go. Our chances of moving into that better design are much greater if the design we have is as clean as we can make it.

19/22

On the other hand, a "quick and dirty" design is mostly dirty and rarely quick. Mind you, that doesn't mean we can't just use a simple solution now, and put in a more robust one later. We can do that: but we need to put the simple one in cleanly.

20/22

Arguably, our simple solution should be put in /more/ cleanly, because it is more likely to need to be taken out.

21/22

To go fast, we have to go clean. Dirty code isn't technical debt. The surgeon can't usefully save time by only sterilizing some instruments. We can't usefully save time by writing sloppy code. That's not technical debt. That's sabotage.

22/22