Technical Debt: What It Costs a Business
What is technical debt?
Technical debt is the pending work a piece of software builds up when it is developed or maintained by taking shortcuts: code nobody documented, patches on top of patches, outdated dependencies or a technology that is no longer supported. Like financial debt, it lets you move faster today in exchange for paying interest later. The interest is the extra time every change takes and the risk that something breaks.
Not all technical debt is a mistake. Sometimes it is a conscious decision, such as releasing a first version sooner. The problem starts when nobody records it or plans to pay it off.
Technical debt examples
- An old desktop application that runs invoicing and that only one person knows how to change.
- Pricing rules spread across forms, reports and macros, with no documentation.
- A manual ERP integration that works by exporting and importing files.
- Code copied in several places, so one change has to be made five times.
- No automated tests, so every update has to be tested by hand.
- A database without keys or validation, full of duplicates and empty fields.
The cost of technical debt
The cost rarely shows up on an invoice. You see it elsewhere: small changes take weeks, every update causes errors somewhere else, the business can't integrate new systems and knowledge depends on specific people. When the technology loses support, security and continuity risk is added on top.
How to reduce technical debt
- Take inventory: which modules exist, who uses them, what rules they contain and what they integrate with.
- Prioritize by risk and impact, not by age.
- Set aside time in every development cycle to pay down debt, just as you do for features.
- Add tests before touching critical parts.
- Modernize in phases when the system is too critical to replace in one go.
When to pay down technical debt
There comes a point when maintaining the system costs more than modernizing it: when every change is a risk, when the technology is no longer supported or when it blocks integrations the business needs. Then the question becomes whether to refactor piece by piece or rewrite. The answer depends on how much value the business rules inside the system have and whether they can be extracted without stopping operations.
Technical debt and modernization at DPI
DPI's guides to migrating from Visual FoxPro and from Microsoft Access to .NET deal with this problem: applications that hold years of business rules and undocumented knowledge, and that need to be modernized in phases without stopping operations. DPI's custom development covers the design, integration and production deployment of the new system.