Technical debt is like ketchup
Short By Dave Ward. Posted October 15, 2012
Have you ever tried washing dried, day-old ketchup off a dish? It’s not fun. What would have taken just a couple seconds to rinse off while it was still fresh can take minutes and multiple attempts to scrub off later.
Worse, the realisation that you’re going to have to deal with the dried ketchup is most likely to come right when you need to do something else with that dish the most.
As you let ketchup (and other foods) accumulate on your dishes without cleaning them immediately, eventually your entire collection of dishes is unusable.
Some dishes are more disposable than others. For some dishes, you’re eventually more likely to throw the dish out and start over with a new one than find a way to make the ketchup-spackled disaster you’ve created serviceable again.
Seriously though
One of the hardest parts of software development is simplifying and explaining it to the non-technical people who write the checks. 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.
Similar posts
What do you think?
I appreciate all of your comments, but please try to stay on topic. If you have a question unrelated to this post, I recommend posting on the ASP.NET forums or Stack Overflow instead.
If you're replying to another comment, use the threading feature by clicking "Reply to this comment" before submitting your own.
This article arrived in my inbox like manna from heaven. Businesses can pay now or pay later. Usually this means they pay MORE later.
I can’t tell you how many times the business will dismiss “non-critical” error log messages only to have new sites launch on inherited bad code. Next thing you know, people can’t place orders and business owners wonder why it takes you all day to go through 500MB of stack traces.
Business owners are my biggest pain point. They are so near sighted.
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.
I think it’s a fair point that once the ketchup has hardened on easily replaceable dishes, it’s sometimes better to refactor them into the garbage than try to clean up the ketchup. A good argument for loose coupling and single responsibility, so your dishes are more like paper plates than fine china.
On the other hand, I run across so much code day-to-day that could obviously have been “rinsed off” when it was written, with almost no extra work or overhead necessary. It’s so much easier to clean these things up right when you’re working on them and the code/structure is fresh in your mind. A few months or years later, I agree that it’s often futile or even dangerous.
Impressed with the metaphor extension. ;^)
The original point was well taken; it’s the implication that Spolsky’s article supports cleaning ketchup that needed a quick realignment. Technical debt didn’t kill Netscape. The thought that they could cope with that debt and remain competitive by declaring code bankruptcy was a business-fatal mistake. Don’t throw away the baby with the ketchup! (Warning: Metaphor implosion.) Even Mac OS started over with two mature codebases.
But if code regularly looks crufty, there’s a deeper problem. At that point, the Spolsky article that begs reviewing is The Guerrilla Guide to Interviewing, particularly the portion on “Hire or No Hire”:
There are only two possible outcomes to this decision: Hire or No Hire. There is no other possible answer. Never say, “Hire, but not for my team.”… If you find yourself tempted to say “Hire, but not in my team,” simply translate that mechanically to “No Hire” and you’ll be OK.
…
Never say “Maybe, I can’t tell.” If you can’t tell, that means No Hire. It’s really easier than you’d think. Can’t tell? Just say no! If you are on the fence, that means No Hire. … Mechanically translate all the waffling to “no” and you’ll be all right.
This is ultimately an extension of Ward’s original message, I think — “Be good coders”. Don’t hemorrhage ketchup on someone’s clean plate. If someone’s code always starts out crufty, tell them the story of the ketchup and see if it takes.
But if you’re tempted to tell non-technical folk about ketchup, the problem’s probably big enough that it’s time to ditch the metaphors and refactor the hiring process.
I think there’s a deeper problem when you bring hiring (and firing) into the mix. By definition, it’s impossible for every company to hire top 10% developers. If you’re Joel Spolsky, you have the luxury of hiring only the best of the best, but most of us can’t lean on that alone.
There’s value in finding simple guidelines for how to explain the intangibles of our craft to non-technical types and to developers who are still learning or just haven’t seen the light about their craft yet. Sometimes the tiniest course corrections, like envisioning their crufty code in a different way, can send developers down a virtuous spiral of self-improvement. Sometimes there’s a sentiment that code is “good enough” if it gets the job done by the deadline, and people don’t make the connection between future troubles (or have moved on to other projects by then) and being sloppy at the time that the code was written.