Did you miss the rather common example of “Hey Boss, I estimate that that task is going to take 4 days to do.” “I need something in 2 days” “Oookay, but it’s going to be kludgey and I’ll need some time to do it properly later” “Just get it done.” …and there is never time to go back and make it right. It’s not that I don’t know it’s bad code, but it’s that I’m not given the resources to do it properly. Dare to argue with the Boss to try and get it done properly? Then you’re not a ‘team player’ and will be first out the door the next time they feel the need to ‘streamline’. Sure, jump ship and try to find a better workplace – but almost all of them are exactly the same.

I’d like to consider another category as technical debt. Decisions made long ago and correct at the time that have been superseded by another direction. For example, technology A was the enterprise standard at the time. Since then, the enterprise has chosen technology B and now one or more project(s) are on the “we need to get rid of” technology stack. Someone has to bite the bullet and suck up the cost of moving sideways to another technology more in-line with the latest enterprise thinking. I’d consider that as technical debt even though at the time of the decision there was no technical debt.

Nice article, enjoyed the style and the !important example is a very good one.

As Rob Tuley also alludes to, is the distinction between bad code and purposeful technical debt important?

I think Martin Fowler does a great job of explaining the point of view (http://martinfowler.com/bliki/TechnicalDebtQuadrant.html) whereby there are various ways of creating/accruing bad code/tech debt but it’s how/if/when you pay it off (or indeed try to prevent) that is most interesting.

It’s interesting to think about “bad code” as technical debt that was accepted explicitally due to urgency of the hiring process or the quality of engineers you could afford.

Setting a dream team on whatever you’re trying to achieve is expensive in both opportunity cost (what else might they have achieved elsewhere) and actual budget costs. So I think you can invoke “bad code” tech debt quite explicitally by trying something but knowing the team is weaker so the quality and application sustainability may suffer. Repayments here include learning, or drafting in outside help like yourself at a critical junction when success of product has arrived without the underlying quality needed.

Hey Harry,

Really nice article.

I thought it was brave to make the “coding” argument seeing as your area is CSS, but your examples transfer surprisingly well to straight code, and I think you did a great job with your analogies – in fact I’d go so far to add that debt interest (hacks on hacks on hacks) is exponential; it’s so much more difficult to understand the primary intent and then fix bad code when it’s teetering on a Jenga tower of prior hacks.

I’m writing a similar article at the moment very much in the same vein, having spent the last few years being pulled into some super-spaghetti junction projects to refactor them, and I’ll definitely reference this article.

All the best!