Stephan Schmidt

Reasons for Technical Debt

What drives technical debt?


“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. [..]. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt” -Ward Cunningham

Since then, the understanding of technical debt has widened. My take: Technical debt is code that is not as easy to change or extend as it could be.

A lot has been said and written about technical debt. Nothing hits the nail though. Most analysis is superficial or stays at the surface and doesn’t go deep enough searching for drivers. If we dig deeper to find drivers for technical debt, we end up with three drivers:

  1. Neglected Maintenance
  • Not upgrading libraries & frameworks
  • Not upgrading systems
  • No continuous refactoring
  • Unused code, feature flags, and configurations
  1. Shortcuts
  • Not following architecture and guidelines (“SQL in controller”)
  • Due to pressure, lacking skills & lacking professionalism
  • Low test coverage
  1. Unaligned with Business
  • Problem not researched and understood
  • Things not easy to change or extend that often change
  • Wrong systems (database) for the job
  • No/unaligned tech vision
  1. Overengineering
  • Gold plating

To reduce existing and prevent new technical debt, we need to work on the main drivers for technical debt.

Neglected Maintenance. Do your maintenance. Do not deviate. Upgrade libraries, frameworks and systems in time. Don’t skip database versions. Every feature is an opportunity to refactor code to make it reflect reality.

Shortcuts. Don’t take shortcuts. Give pushback on unrealistic deadlines that would push you taking shortcuts. Keep writing tests, or start writing tests. Just as the CFO would not drop double accounting, don’t drop testing. Just say no!

Unaligned with Business. Align with business all the time. Have a tech vision and tech strategy that is aligned with the company vision and business strategy. Research the problem before you start coding. Chose the right tools for the job, not the tools that are currently the hot thing.

Overengineering Apply the right level of engineering. If you need to go to the moon, don’t build something that can go to Mars.

Keeping the drivers in mind will eliminate the root causes of technical debt. No technical debt makes business and developers happier and lets you react faster to the market and to new ideas.

More in my Upcoming Book

Amazing CTO Book Cover

Technical Debt

The essential guide

Everyone has technical debt. Eveyone wants to get out of technical debt.

Join CTO Newsletter

Join more than 2700 CTOs and Engineering Managers

More Stuff from Stephan

Other interesting articles for CTOs

Best books for CTOThe CTO BookExperienced CTO CoachEngineering Manager CoachingConsulting and Workshops to Save you TimeCTO MentorCTO MentoringCTO NewsletterHow many developers do you need?Postgres for Everything Product Roadmaps for CTOsHow to become a CTO in a company - a career path

Other Articles

How To Succeed With A Rewrite - And Why They Fail

Musings about error handling mechanisms in programming languages

CTO vs CEO - how cooperation can work

Tests Are Bad For Developers

Accidental vs. Strategic Technical Debt