In Defence of Tech Debt

Adam Donaghy
Jan 9, 2017 · 2 min read

I’ve been thinking a lot about tech debt recently, the benefits and the detriments and what to do about it. I’ve come to the conclusion that “You can buy a house with a little cash and a loan from the bank, but too much debt and no repayments, you’ll lose the house”. Technical debt gets a bad wrap because it’s misunderstood. If it’s managed correctly it’s awesome, you get new features quickly and keep the features when you pay off the debt in the future. If it’s not managed correctly your codebase can go to shit and making the smallest change can screw everything up.

Why does technical debt happen?

  • Reckless/Deliberate Debt — The gung-ho approach. Pressure gets to the team and they just focus on “making it work” without caring about how they made it work, deliberately violating best practices.
  • Prudent/Deliberate Debt — The value of shipping with a poorly written feature and fixing it in the future, is far greater than the cost of refactoring. The team is fully aware of how they’re incurring debt and, have a plan of how to pay off the debt after they’ve shipped the feature.
  • Reckless/Inadvertent — The team is ignorant of best practices, and writes absolute junk.
  • Prudent/Inadvertent —Only after having written the solution do you realise how it should have been written. This is usually a mix of experience and learning on the job. This kind of debt is the best kind because it points towards a high quality solution that has long term support.

Why does code quality and debt matter?

  • If you write good code making changes in the future is easier
  • It’s faster to write new stuff ( especially if there’s automated testing )
  • Shared knowledge in the team make the code easier to maintain when people leave the project

What can you do about it?