Technical debt is one of those crucially important concepts that can alter the course of an entire company if left unchecked, but it can be incredibly difficult to clearly convey that to non-technical stakeholders.

Your negative notions about what debt is might be what a “business guy” considers productive leverage. You can just pay that debt back after the new feature makes us all rich, right? I wonder if that has ever happened?

Next time, tell them it’s like ketchup.

The metaphor is that ketchup gets nasty if you leave it on a plate and don't clean it immediately. Fixing known cruddy code (or cruddy architecture) sooner than later is well motivated.

But Ward makes the mistake of linking to one of my favorite Joel on Software pieces that talks about rewriting code, and Joel's suggestion is precisely that the ketchup shouldn't be cleaned. Ward says "technical debt" killed Netscape. No, not at all, says Joel. It was their self-defeating choice to throw out the ketchup.

So I thought I'd save my response. How and when to rewrite suboptimal but operational code is one of the toughest quandaries we've got. So, without further ado, um, me.

Um... Interesting to link to Spolsky here. That's one of my favorites from him. It's great.

But it's worth mentioning that he's arguing for you to consider never cleaning the ketchup, and that's the most important lesson Joel wanted you to get from that article, imo. Refactor, don't rewrite.

Here's a snippet from Joel (talking about Netscape's rewrite to start, which is why Ward included it):

Before Borland's new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby!

(Emphasis mine. "As if source code rusted" is one of my mantras.)

Ketchup's entirely the wrong metaphor. You can't slowly replace ketchup dollop by dollop and come out with something that performs an order of magnitude better (we could stretch and talk about petrification, but I think the metaphor collapses at some point).

Ward's point is well taken. Don't build cruft on top of cruft thinking you'll clean it out later. But Spolsky's point, where you can assume at least competent code, is that you want to keep complex code because it works.

The real skill, and this is where a nontechnical lead is all but worthless, is being able to tell the cruft from the craft, and what needs refactoring NOW versus what can wait until later.