How to intelligently manage technology debt?

Technology debt is a cause of inefficient software development, security vulnerabilities and unfunctional software.  And while everybody agrees that technology debt should be tackled, the budgets, available time, willingness and resources are lacking for remediation of it.  In this short article recommendations for efficient technology debt remediations are provided.

When a software development team faces time constraints to meet specific deadlines, they might implement solutions that work effectively but lack optimal software design and quality. There are both short- and long-term compounding effects directly impacting the business. In near term, often tech debt causes instability, performance, security risks, operational fragility, decreased resilience, and poor customer experience. In the long-term the business’s overall future is hampered with challenges relating to lower-quality unscalable product and deteriorated security.

The technology debt (abbr. tech debt) is an exchange of long-term issues for short-term temporary solutions. Aggravating the matter is the fact that tech debt is often tied to outdated and unsupported software, i.e., legacy systems.  The latter refers to the software such as aged software frameworks, outdated 3^rd party components and obsolete programming languages that increase risks for critical system failures, security breaches or data loss incidents. This can lead to more customer support calls, lower customer satisfaction and higher personnel unsatisfaction. Consequently, the tech debt can be translated into tangible financial cost in terms of lost business, decreased revenue, regulatory fines or reputational damage.

Nevertheless, there is a cost in mitigating the technology debt associated and its mitigation benefits do not necessarily immediately surface.  To strike the right balance between tech debt mitigation costs and immediate mitigation benefits here are some recommendations on how to deal with technological debt in a feasible manner.

Recommendation 1: Identify, Assess, Manage, Monitor and Communicate

Technology debt is not always negative, as taking on some tech debt can often lead to quicker market entry. However, it is critical to prevent it from spiralling out of the control.

Ensuring mechanisms for the tech debt management includes establishing and monitoring software quality criteria such code duplication, cyclomatic[1] complexity, violation of coding standards. To aid there are Software Intelligence tools that can automate software quality scans. A skilled development team working with product team will have the ability to critically analyse and make sense of those software quality data is a key.

The different types of tech debt such as suboptimal software design, poor code practices and legacy should be assessed against potentially adverse impacts they might cause. The negative impacts should be communicated to the business and the product owners so that management of the tech debt is re-occurring activity that is budgeted, communicated and planned.

Recommendation 2:  Not all tech debt is equal – prioritise continuously!

Due to limited resources, it is recommended that the tech debt mitigation is stringently prioritised based on a set of the defined criteria. The prioritization should start with a strategic view such as digital & tech product strategy or agreed metrics that align to the roadmap goals.

Major upcoming product roadmap items and customer pain points are useful inputs for tech debt mitigation prioritization.

Another highly important criterium is a rate of code change. It is higher priority to minimise tech debt in the pieces of code e.g., classes and methods, that change or are foreseen to change frequently. By having a clean code that change often, inclusion of new software functionalities is accelerated. Since in a huge code base the rate of code change is hard to pinpoint the software intelligence can be here of aid.

Prioritise phasing out the outdated and unsupported software. The longer tech relies on outdated technologies, the more difficult and time- and effort-intensive, it becomes to migrate it to the new versions. Also, the deprecated technologies may have security vulnerabilities that can be exploited. This can be compared to unpaid financial debt that exponentially grows as the time elapses.

Prioritize continuous refactoring. Restructuring existing code without changing its external behaviour is referred as refactoring. Executing refactoring keeps the codebase clean and manageable and ready for changes. Friday afternoons might be a perfect timeslot for software teams to jointly discuss and address tech debt issues.

Recommendation 3: Apply modern design and quality best practices

Software components should be as decoupled. If the changes in one part of the software system break and cause a failure in another seemingly unrelated part of the software system, it’s a sign that the code is tightly coupled, which is a form of tech debt relating to the bad software design. Such lack of modularity makes updates and changes tedious and error-prone, as each change could potentially affect the entire system. A modular design aids to locally containing negative effects of the system failures and tech debt.  Therefore, a good system software architecture, e.g., modular, event-driven, micro-service design should be the “North Star”.

Compliance with organisation code best practices and security guidelines, in conjunction with regular code peer-reviews and automated code quality scans are critical. This can often help identify issues before they become ingrained in the system.  Subsequently, good testing practices (e.g., performance and vulnerability) are highly beneficial.

Recommendation 4: Consider outsource the Tech Debt

This can be done in multiple ways that allow for the development team to have oversight and alignment. The solution should be tailored for the strategic aims of the tech debt work. This can be simply done by:

• Procuring software solutions and 3rd party services – in this case the cost of tech debt remediation is spread by several customers, i.e., your company does no longer carry the cost of tech debt remediation alone. Also, errors can be identified quicker in a large user base and proactively fixed for all customers. Leverage 3^rd party services to ‘fast follow’ the development efforts to ensure tech debt is kept reasonable for the business outcomes desired.
• Use building blocks in your development that leverage on shared resources from vetted, proven projects. For example, open-source libraries used in tech solutions should be supported by many active contributors which ensures good quality and IT-security. This could be expanded into an internal open-sourcing of code.
• Automatise management – updates and patching of outdated software can be outsourced to third parties such as Platform-as-a-Service providers such as Azure, AWS, GCP, etc. This option allows the development teams to focus on business differentiating activities while having the peace of mind that business-as-usual is given due attention.

Whilst the challenge of technical debt is a commonplace issue, most IT-departments find themselves buried under a mountain of debt threatening to derail the business’s strategic ambitions. Our recommendations help teams to mitigate the risks. And the Infosys Consulting CIO Advisory experienced team is available to bring in our expertise to partner with your business to efficiently tackle this challenge.

[1] This measures the complexity of your code by counting the number of independent paths through it. Higher numbers can indicate more tech debt, as the code is likely to be harder to understand and maintain.