Table of Contents
It’s always good to stay out of debt, especially when it’s technical debt. In brief, technical debt occurs when your IT department chooses the easy way to fix a glitch, rather than the right way, and it can lead to some disastrous outcomes. Eventually, these debts must be paid.
Consider this real-world situation. In October 2010, Instagram launched its iPhone app, which it ran off a single server in Los Angeles. The traffic that ensued from the launch nearly crashed the server because of the company’s unpreparedness, and Instagram had to move in three days to a cloud-hosted server that could handle the traffic. Since then, co-founder Mike Krieger now works constantly to keep technical debt at bay.
Debt Strategies
Anyone who works in software development understands why people allow technical debt to build up. Sometimes something needs to work quickly, and your IT department doesn’t have the time to create the right fix. There are several strategies those who work in IT utilize to pay down technical debt, and paying this debt down a little at a time can help prevent bigger problems in the future. Below are several things your IT department can use to prevent disaster.
Think forward
Having an initial strategy to think through those critical technical issues helps you avoid having to rework code in the future. Not taking short cuts in the first place, when developing solutions, avoids technical debt before major problems have a chance to develop.
Make one person responsible
When you have a team, make one person responsible for the architecture of the program. This person guides the rest of the team, making technical decisions on the structural aspects of the software. Having one person guide the team in this way allows it to keep new technical debt from developing. This individual should also motivate the team to address any additional technical debt discovered, dealing with it when appropriate.
Be aware
IT staff need to understand that they are part of a larger group than just their work team or even the IT department. Their work affects the whole organization. Understanding how the whole system works together allows people to take advantage of the innate assets in any software These assets might include bits of code, patterns, services, guidelines, or anything else you can reuse to make the code work more efficiently. By reusing existing assets your IT department can avoid technical debt, an important strategy to understand, as they won’t then have to rebuild something that’s already in place.
Refactor debt
Software refactoring reduces complexity in the architecture of code, making it simpler without changing its dynamics. You can essentially refactor technical debt away, whether refactoring codes, databases or user interfaces. Though typically making only very small changes, refactoring by renaming operations or splitting database columns are ways to simplify the architecture and make it easier for future fixes. Reworking software, however, is a much more substantial task and requires careful planning to fix what wasn’t done right in the first place. Often reworking will be done by the owner of the architecture, who understands how the software is structured, for the product owner.
Continuously regression test
By running a comprehensive regression test suite regularly, your IT department can find problems easily and make sure software still runs as it should. Test suites help identify the defects in code so that programmers can fix them right away or back out of the changes.
Accept specific technical debt
In the short-term, sometimes accepting technical debt is necessary. Perhaps it’s for a marketing experiment or new component, but accepting this technical debt also means accepting the responsibility to pay it down. And for those who have good regression testing in place, taking on this technical debt can be done without much risk.
Conclusion
According to Wavestone US – previously known as WGroup – an IT consulting firm with a peer-to-peer approach to IT strategy, cost optimization, and operational improvements, technical debt should be serviced, and eliminated. In one of their blogs on the subject, they talk about a vendor for a large organization that fixed bugs any time there was a problem. Each time they did so, they spent time making the code less complex, each time making the system just a bit more efficient while fixing each issue. Over the course of five years, while fixing the bugs and without any plan to do so, the vendor eventually paid off the technical debt in full.
There are a number of really good resources online that address the problem of technical debt and how to fix it. It’s a real thing, and businesses these days require agility within their IT departments. Making workable plans to deal with technical debt makes sense. Just like servicing your financial debt, you want to pay the technical debt down too, so that it doesn’t come collecting when you least expect it. Those that don’t run the risk of strangling their business’s IT infrastructure.
