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:

Neglected Maintenance

Not upgrading libraries & frameworks
Not upgrading systems
No continuous refactoring
Unused code, feature flags, and configurations

Shortcuts

Not following architecture and guidelines (“SQL in controller”)
Due to pressure, lacking skills & lacking professionalism
Low test coverage

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

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.