time lapse photo of lined up dominoes falling over

How to Manage Technical Debt When Preparing for a Digital Transformation

5 minute read
Sebastian Velez avatar
Any digital transformation strategy must consider technical debt, because if left unmanaged, it can greatly hinder the pace of an organization’s innovation.

Any digital transformation strategy must consider technical debt, because if left unmanaged, it can greatly hinder the pace of an organization’s innovation.

While there are several different definitions of technical debt, in this instance we are referring to any development code with the potential to cause maintenance and productivity problems down the line.

It can be common for products to have some sort of technical debt, which may stem from libraries or source code that's external to the product. But, the important thing — especially during a digital transformation initiative — is to make sure it's kept under control. Otherwise, it becomes too difficult to rectify, like a snowball rolling downhill, constantly growing and collecting sticks and rocks along the way.

Common Technical Debt Problems

Technical debt can cause a myriad of different problems, often because the code has become far too complex, or because changing some elements of the code has led to new defects elsewhere in the product. Code can also be very hard to understand and adding new features often is slow, adding to the challenge.

Some organizations have several legacy products to upgrade or one big product that should be broken up into multiple microservices, which isn't possible yet. Other times, duplicate code needs to be updated or changed in multiple places to fix the problem, making it doubly complicated to compete with other players in the industry. I’ve also seen companies struggling to remove obsolete libraries with security or performance issues due to the high impact of the change.

If a product reaches this point, companies will sometimes want to start from scratch, but it’s preferable, and completely possible, to avoid that extreme measure by taking full control of your technical debt. 

Related Article: How CIOs Can Manage Digital Transformation

Identify Issues and Prioritize Fixes

The first step in achieving control is to identify and prioritize your technical debt by determining how important each issue is to your business. Always consider how much debt there is and how critical the product is for your overall business strategy.

It’s not practical to alter code or focus efforts on barely used software. The idea is to focus on items that will have an impact on business goals. Create a working culture that highlights the importance of technical debt and how it relates to the business. And find tools to help you pinpoint the tech debt per component and the rate of modification, allowing you to more clearly identify where to focus your efforts — they're out there.

By taking this approach of “identify and prioritize,” companies can start to progressively solve their technical debt problems and implement engineering practices that make products more successful, both from an engineering standpoint and a customer standpoint.

Related Article: Digital Transformation: Why Now?

Work With Automated Tools and Experts

The process of transforming a legacy product is a minefield of potential coding issues, but many tools can help with this by improving code quality.

Static code analysis tools such as SonarQube (one of the most popular), JSLint, ReSharper, among others, can be used to scan existing code and find patterns of technical debt. Even though these types of tools are fully automated, using them with caution. Involve an expert who can judge the urgency of the issues found. 

Learning Opportunities

It’s good practice to use these tools as part of a comprehensive technical debt assessment on the products or modules that you use the most. Large organizations that have dozens or even hundreds of products are likely to have technical debt across all of them, so prioritizing business goals is essential for deciding which products to modify or improve first.

Related Article: The Elephant in the Digital Transformation Room: The Long Tail of Legacy Tech

Long-Term Stability > Short-Term Gains

When transforming your business with technology, short-term disruption is fairly simple to accomplish, but it’s ultimately a loss if you can’t maintain and improve that rate of innovation over time. Research shows the most innovative players ensure the stability of their products in the long run. Based on evidence outlined in Nicole Forsgren’s book "Accelerate," you no longer have to choose speed or stability. Rather, quality IT practices should enable both.

Achieving this combination of speed and stability is why we operate to a standard in which all of our projects keep track of technical debt, but it’s still really common for clients to bring existing products that are suffering from past mistakes.

A common complaint among clients is: “we solved one bug but opened three new ones.” Lack of standards, unclear architecture and no automated code are all culprits here, but rewriting the product is often not an option due to business pressure to deliver features. Issues like these can in turn delay implementing and deploying changes.

Companies will sometimes prioritize short-term gains over stability, implementing new features or products to capitalize on customer trends without thinking about the long-term technical debt they are creating. By committing to a long-term solution and partnering with the right experts, organizations can wipe the technical slate clean and see the true value of their digital transformation.

Related Article: An Iterative Approach to Digital Transformation

Set Your Organization Up for Long-Term Success

Whether it’s a result of bad programming practices, repeated code or simply a slow-moving upgrade of legacy systems, technical debt will seriously hinder your ability to innovate in the long-term, rendering earlier innovations useless. Any company looking to manage their technical debt in preparation for a digital transformation should work to identify and prioritize these issues as part of the development cycle, while also tying everything to their business goals.

About the author

Sebastian Velez

Sebastian Velez is head of technology and also oversees PSL’s training and development program and R&D innovation lab. He has been in the industry for more than a decade, with experience as a developer, software architect, scrum master and college professor.