Skip to content

24 ways to impress your friends

We Need to Talk About Technical Debt

6 Comments

Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.

Got something to add? You can leave a comment below.

Rande Knight

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.

Steve

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.

Graham Russell

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.

Rob Tuley

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.

Dave Stewart

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!

Steve

Good article. I’d like to add a bigger concern is unnecessary nesting or using ids as parent selectors. That’s the reason we use the important in the first place, because the logic behind all the unncessary specifity gets so complicated it takes us too long to do our job and just style it.

example:
#component ul li a span.

While used for one isolated situation this may seem fine, but when wrapped in another component, or a state change, or looks different in a different screen size or needs a browser/device specific fix then it multiplies the amount of overrides you need. Sometimes you can’t avoid all the overrides, but we can avoid unnecessary nesting.

consider this:
@media (max-width:768){ .ff body.modelOpen .modal .drawer.expanded .accordian .accordianInner.expanded #component ul li span
}
Then this:
@media (max-width:768){ .ff body.modelOpen .modal .drawer.expanded .accordian .accordianInner.expanded #component ul li span
}

Impress us

Be friendly / use Textile