Technical debt is a complex topic. Many factors contribute to it and it tends to grow over time. Implementation shortcuts combined with quick-and-dirty fixes contribute to the buildup. But that’s not the worst of it.
The biggest problem with technical debt is that it creeps up on you. Imagine a dam with water building up behind it. The trickle of water through the dam increases over time but is easily directed away. Suddenly one day, the dam develops a major fissure and the trickle becomes a flood.
It’s often similar with technical debt. It keeps building up but is of no major concern — until one day a tipping point is reached and the software becomes slow and unpredictable. The development team tries to fix it but the code base is so dysfunctional that no one can fully comprehend the causes of the problems.
A Real-Life Nightmare
This scenario is a software development team’s worst nightmare. Regrettably, it happens more often than any of us would like to admit. All those rushed attempts at getting the software deployed on time have created a monster.
Technical debt won’t go away. We will always cut corners and leave loose ends in an effort to satisfy the boss or the stakeholders. We tell ourselves that we’ll go back and clean things up after the deployment but it never happens.
The important point is to be able to identify technical debt and take corrective action before the dam breaks. Software systems rarely suffer catastrophic failures. They decay over time.
Here are 7 warning signs to watch out for:
- The system load keeps growing. Conduct load testing. Watch memory utilization, disk reads and writes, CPU usage, network activity, thread creation, etc. The precise measured values are not as important as the trends over time.
- Defect rates climb. Pull defect reports. The number of defects is not as important as the trend and the locations. Watch for a high percentage of defects within a single software component or module.
- Problems proliferate. Monitor problem types. The same problem appearing in different software components or modules indicates poor design.
- New features mean new bugs. Look at defect timing. New functionality will always introduce new defects. If the number of defects associated with new features grows over time, the code is fragile.
- It keeps taking longer. Evaluate defect repair times. The time spent fixing defects should be fairly constant or even decline. If it continues to increase, technical debt is the likely cause.
- Complaints get louder. Listen to the team. If the team complains about a software component that is hard to understand and/or difficult to test, it is a candidate for refactoring or a complete re-write.
- Source code thrashing increases. Count check-ins. Software modules that are changed frequently indicate poor design or poor implementation.
Listen to the End Users! If their complaints increase over time or they frequently complain about the same issues, something is seriously wrong.
Unlike some bloggers, I don’t believe that technical debt is entirely bad. I don’t accept the idea that technical debt should be avoided at all times. Like anything else, technical debt should be monitored and evaluated. Take corrective action as needed depending upon the nature of your software and your risk tolerance.