Go to portal
Technical debt is a phrase that tends to come up quite often for any IT platform of a certain age. Just like financial debt, creating technical debt is not an ideal solution. However, sometimes business needs and deadlines can necessitate it.
Example
You’ve got to create some new workflows which require integrating several systems together. You can make a clunky yet functional design or you could create an elegant solution. The problem is the elegant solution will take an extra couple of weeks and you’ve noticed there’s a significant slowdown on one of your portals and your boss is starting to grumble about a new application he wanted up and running last quarter.
Why technical debt matters
Without working serious overtime, your only workable solution to the above example may be to take that shortcut. But next time you want to build on that workflow and integrate extra features, it will be much slower to do so. I will also be more prone to breaking because it wasn’t built with scaling in mind.
This is why platform owners and managers should care about technical debt. Though managers’ KPIs often focus on performance and delivery of functionality on the surface, a key invisible measurement of success is technical debt. It’s very comparable to the theory behind financial debt; If you borrow too much at once then it gets trickier and trickier to pay back. You’ll then struggle to afford what you actually want due to constant repayments.
But I can’t afford to stop my platform development to fix technical debt…
At first glance, it can appear that sorting out technical debt and bringing it under control will bring your platform development to a grinding halt. However, another way to look at this is the consequences of not sorting things out before a crisis point is reached. If your instance becomes very unwieldy and unstable to build upon it can almost be like hitting your credit limit – you need an emergency intervention in order to keep on functioning. At this point, you have lost control. You will, therefore, have no choice but to pay attention to the issue. Any other goals will fall to the wayside.
Put like this, it’s clearly optimal not to leave it until the last possible moment to fix things. Plan ahead and assess which less busy periods might be suitable for working on your technical debt backlog. This will allow you to retain control of your schedule, rather than hitting an unexpected roadblock that significantly hampers you in busier times.
Conclusion
As with many things, prevention is better (and more time effective) than cure. If you have time then futureproof your solutions. If not then ensure the code you do develop follows rigorous best practices. A real-time code checker can tackle issues at source and prevent many hours of technical debt further down the line.
