So the other day I saw an interesting tweet from a slide at PyCon that talked about technical debt:

and so I turned to my manager and I asked her if she knew what technical debt was, and she said she vaguely recalled the term. In my book, that’s not very good, so I’m going to try and spread the gospel about technical debt and how to eventually get yourself out of it. It might just save a developer’s life!

What is Technical Debt anyways?

Technical debt resembles real debt in the way that it is accrued through taking a shortcut. When you go to the store and buy something with a credit card, you’re taking a shortcut. Instead of saving up and earning that money, you’re buying it on credit and paying it back later. It’s like a money shortcut that I abuse religiously.


Technical debt works the same way, you take a shortcut that you say to yourself at 1am when you’re half drunk and half mad trying to hit a deadline that you’ll “fix later” (as an aside, later never actually comes). These shortcuts come in the way of sloppy code, black magic, and inline styles. We’ve all done this before, I am not a stranger to !important tags in CSS that work because god dammit this needs to get done. Or commenting //voodoo on a javascript that just works but I’m not honestly sure why. Even worse is when I come into some legacy code that has that kind of commenting system in it.


This is how debt is created, through satanic ritual and desperation. This black magic that you pulled at the very last minute to hit a deadline becomes a mess down the line in various ways. Your shortcut has to be paid off, and usually it’s through confusion by another developer who has to spend twice as long finding out exactly what you did and exactly why you did it, to clean it up.

What causes technical debt?

  1. Your manager telling you the deadline moved up two weeks, and it’s time to get this out the door right now.
  2. You forgot about this project and oh shit it’s due tomorrow
  3. You have honestly no idea what you’re doing
  4. The last guy had no idea what he was doing either
  5. No one is going to test this code anyways, so I won’t get caught implementing this hack


Why should I care about Technical Debt?

Just like your student loans, technical debt accrues interest, and it has to be paid eventually. When you’re building a system and a lot of the early code is built through black magic and shortcuts, you’re building on top of this code with more hacks, and you depend on these hacks! Building a pyramid on an unstable foundation is a bad idea, building an application on an unstable code base is an even worse idea. If you ignore technical debt it’s going to haunt you later when you can no longer build on top of the foundation without bringing everything down or spending hours trying to understand how x works.


This debt is a dam in your process, and every new person you try to bring onto the project is going to be faced with helping you pay off your mistakes in the past. How are you going to explain to management the reason why your new intern can’t style a menu is because you put five thousand important tags in style.css and accidentally edited the bootstrap code so you could get your overlays just so at 3am before launch?

Don’t get me wrong, you will always accrue some debt, but you should have a plan to pay it off eventually.

How to pay off debt

Make an offering to the gods.


But seriously, do make an offering every month. Your animal sacrifice comes in the way of two or three days every month where you go back through your code base and start to rip things out that bug you. Inline styles, bad script calls, voodoo black magic. Set aside one or two days at the end of every sprint (if you’re doing agile) and fix things. If you didn’t know what technical debt was, or didn’t care what it was until now, it’s going to be a daunting task. Just like paying off credit cards, making a payment every month will eventually get you debt free. However if you’re looking at the code base right now and feeling like:


Don’t worry, I have a way to help you. I call it the snowball effect. Start with the small fixes that you can get done relatively quickly, cleaning up the CSS, beautifying the code, maybe moving all those JS calls to the footer. Things that might take you ten minutes or less. Once you get the smaller tasks out of the way, move on to the harder tasks, detangling some javascript voodoo, sweeping up some unused styles, redoing some hacks you did the right way. Then finally once you’re groovin’ along and most of your debt is paid off, get to the really difficult things, auditing and reviewing your own code, sanitizing your queries, redoing something you used a jquery plugin for that you really didn’t need.


This method gives you the most important part of tackling a problem: momentum. Starting with small stuff pushes you forward a little more and gets you over that “oh shit there is so much to do” hump and into paying your debt off and getting in the clear. Yes, you will break a lot of stuff, but sometimes you have to tear down a house in order to put up a sweet mansion.

Paying down your debt not only helps you and your application, but it helps the future generations of developers, and if there is anything a new developer needs, it’s a bright and shiny future. Make these debt days a monthly occurrence and you’ll see your entire build process speed up exponentially. When you’re not wasting time trying to solve old problems, you can spend more time on new problems, and we all know there is never a shortage of those.


Less Debt -> Less Frustration -> More productivity -> (Mythical) Happy Developers!