A server room full of very messy wiring. There are so many cables connecting devices together that you can't see the devices themselves,
Actually relevant image by Happy Tinfoil Cat

Technical debt is one of those things that you completely understand when you run into it, but is really hard to explain to someone who has never worked on a large application. That picture on the left of the messy server room is probably the best illustration of technical debt I’ve ever seen, and you should definitely use it the next time you need to explain technical debt to someone.

You can guess exactly how it happened, can’t you? “I know this is the wrong way to do it but we’ve got to get this server back up NOW so just string a cable over to that other switch and we’ll tidy it up later.” FYI, that never happens just once. “Later” when it’s time to tidy it up never comes either. There’s always something more important than going back and fixing something that technically works.

Even when you have the time to make a change the right way, it’s a huge hassle because the server room is already such a mess. Eventually, it gets so bad it’s just impossible to change anything without first tidying the whole thing up. That’s what technical debt is like in code, it’s just harder to see.

Every time you cut corners to get something out the door quickly, you build up technical debt. You make a little bit more of a mess, and as the mess gets worse and worse, it gets harder and harder to make more changes, just like in the messy server room.

Just like financial debt, sometimes it’s worth taking on technical debt. And just like financial debt, you need to think carefully about it before you take on that debt and you need to have a plan to pay it off. Ignoring the fact that you have technical debt is like ignoring the fact that you’ve maxed out your credit card, it just gets worse if you don’t deal with it. Unlike financial debt you don’t directly get charged interest on technical debt, but every piece of new development you do has to work around your existing debt. If your project is dead and you don’t have to change anything then your technical debt doesn’t matter, but on a project that’s still being updated you’ll eventually have to work around the corners you cut. Every time you do that without tidying up the original mess, you make more and more of a mess until you end up with something like that server room above.

All of this is completely obvious if you’re a developer who has worked on a large project, but technical debt can be really hard to explain to non-technical people because they aren’t programmers. That photo is a fantastic visual metaphor for technical debt, which is why I think it’s so great. Once you have a metaphor like that, you can have a productive conversation about technical debt with a non-programmer because they now have the slightest idea what you’re talking about :)

It would be great if management would just trust the dev team when they say they need time to pay down technical debt instead of continuously pumping out new features, and it’s definitely an issue if different parts of the company don’t trust each other, but even when they do I think it’s reasonable for managers to want to understand what’s going on. As a programmer I certainly understand the urge to yell and stomp your feet about people who don’t understand technical debt (or why sometimes things take way longer than you expected or why adding people to a late project makes it later or why you need to make time for documentation, etc, etc), but you know, it’s a lot more productive to find a way to explain it.