How to Mitigate the Technology Gap and Manage Technical Debt

by

There are always trade offs to be made when you're dealing with keeping your application portfolio up-to-date. You always have several options, whether it be modernization through migration/refactoring or by a sort of "transformative leap". The presence and type of technical debt you have present in your system will dictate how you are able to modernize your application portfolio.

If you start to think about the manner in which technical debt manifests itself you will realize that the presence of technical debt is the difference between whatever is a state of the art application design and your ability to adapt your current offering to that new standard. Below figure 1 to illustrates this:

technology gap
Figure 1

There are three approaches to managing the technology gap and your technical debt as shown in figure 2: refactoring, code migration, and transformation. Refactoring can be used to fix those small non-functional requirements, whereas large non-functional (and some functional) requirements can be aided through modernizing code and updating your infrastructure. Finally, resolving large non-functional and functional requirements can be done by abandoning your old code and transforming your applications.

While it may seem that refactoring and code migration/modernization is doing the job of keeping your technical debt in check, you will reach a point where continuos refactoring won't be able to account for the acceleration of the technology curve. Your ability to keep up will decrease with the fast growth of that technology curve as shown in figure 2.

technology curve
Figure 2

So what happens once you can't keep up with the speed of growth of the technology curve?

You will start the process of hectically refactoring to try and modernize your code. The more you start to fall behind and frantically try to refactor your code, you may feel pressure from stakeholders to buy an off-the-shelf software option. This will be due to the fact that non-technical stakeholders will believe that since you can't keep up with building modernized software now that a build option cannot be feasible at all. This will spur a manic attempt to try and find the trade-offs between a build or buy strategy - and what you will discover is that the same issues of the technology curve gap illustrated in figure 1 plague the software vendor community. You cannot escape the issues of technical debt and adoption of new technology simply by buying new software.

This leads you to the point where continuous refactoring may very well keep close to the best-in-class applications but will always leave you behind having state-of-the-art applications. Eventually in order to keep up you cannot simply refactor, you will need to continuously migrate and transform your code. This means that when you release a new application you will need to immediately start a new project to refactor and modernize that application you just built and released in order for it to continue to be relevant. Incremental steps to maintenance will no longer be adequate. You will have to constantly build and abandon technologies as they fall behind the technology curve.

But this does not mean that you should throw your hands up and give up trying to manage your technical debt, code, or applications. It simply means that you need to adapt to a new "software development paradigm" in order to stay in the game. This post simply demonstrates the necessity of this sort of adaptability in a critical manner.

To read the full post visit here.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|