How do you solve a problem like Technical Debt?

To paraphrase the famous song from the movie ‘Sound of Music’ where the kind nuns throw out this rather perplexing and inexplicably difficult question into the cosmos. Discussions of technical debt can be just as perplexing and unfathomable within organizations, creating deep divisions between the ‘techies’ and ‘business’.

What is Technical Debt?

Let me give you an example. Design has a great idea of adding a block/banner advertising a USP of the company. They want to bake it into the layout of the product pages. They know the scrum teams have a heavy backlog and do not want something too complex. They believe this is a relatively simple change which might, potentially, give large returns, leading to higher conversions.

They sit in the refinement session with the scrum teams. The developers look at the user story. They scratch their heads. ‘Well, we have 5 different versions of the app- some in native HTML, a couple in old school silverlight pages and some in AngularJS and ofcourse, our latest and greatest Angular framework. We will need to add a different implementation for each of the flavors, not to mention, creating components in different technologies(we don’t have any Silverlight knowledge in-house anymore, so might take us longer to figure out!).

The simple user story becomes a feature. They add one user story per tech stack. They need to clean up some parts of the silverlight app before they can begin start working on adding the components. They add another user story to clean it up. What the business thought was a relatively easy ask turns out to be bigger and bigger, as they watch in horror, and shake their heads at each other wondering, ‘Why is this so difficult?’

Types of Technical Debt

All companies have technical debt. The inside joke is that Technical Debt is the way to describe your products that actually make you money. But not all tech debts are created the same. Some are more expensive and more difficult to get out of than others. I will try to classify the three main types of tech debt that organizations may come across in their lifetime.

Legacy Tech stack Debt

Tech landscape changes at a dazzling pace and no matter how current your tech stack is when you choose it, the longer your product is alive, the more dated/legacy it gets. Once a tech product has been around for a while, with no attempt being made to upgrade, 2 things can happen.

a. A new feature needs to be added. There are tools in the market which provide this feature off-the-shelf. However, our tech stack is not compatible with these tools. So we need to reinvent the wheel in a less efficient, possibly risky and buggy fashion, with huge effort.

b. The technology itself arrives at ELTS(End of Lifetime Support)phase, thus leaving the product wide open for security and other issues.

How do you solve a problem like Legacy Tech stack Debt?

There is no one-size fits all answer. For ELTS products, the answer is, in some ways, simpler. The business and Technology have to make hard choices to either retire the product or upgrade/re-platform it. It also gives business a chance to re-look at some features and see if they can upgrade the feature set as a part of migration.

For non-ELTS products, the decisions are trickier. It could then be decided to do a migration in a phased manner, migrating the areas which need new development first, thus phasing out the effort over a period of months or years. Consensus has to be reached on this plan, thus making it clear to all stakeholders that a portion of the time will be spent on this upgrade.

Architectural debt

As an application grows, you need to periodically pause and take stock of the direction in which you are moving and do some course correction along the way. At some point during the lifetime of an application, there are some unintended branches and decisions taken which was a deviation from the original design that it was intended to serve.

This could arise as a result of new methodologies within the industry(DevOps, Microservices), new tech stacks added to the application(SPA, APIs) or just a different direction that the company has taken as a business(business units re-organized/re-structured making the current architectural layout utterly senseless).

In order to structure your application landscape in a way that it makes more sense to your current and future realities, you might need to undertake some refactoring of your architectural landscape.

How do you solve a problem like architectural tech debt?

Your architectural landscape is the foundation on which your entire application stands. Making fundamental changes to your architecture is like trying to remove the bottom most block in a Jenga pyramid. So how do you do it? Slowly and gingerly, one step at a time.

There are methodologies such as Strangler patterns available, where you transform one part of your application to the new design before decommissioning the old layer/service and thus move in a step-by-step manner towards your new architectural layout which is more in keeping with your vision of the present/future.

Code Debt

Code debt is what is accrued by simply, badly written code. I’m so proud of this awesome beautiful code I wrote 2 years ago, said a developer never. Who the hell wrote this crap, asked a developer often, before finding how own name in the code commit for 3 years ago.

Developers’ understanding of coding techniques and the business and system interactions is constantly evolving, leading to many such WTF moments where they are itching to set historic rights wrong. Prolonged, unattended code debt leads to applications that are buggy, less compliant to security features and are less performant. Think of code debt as what happens to a house when you stop cleaning it for a few days. Cobwebs appear, things get progressively messier and difficult to find, and at some point, if left unattended long enough, will be deemed a health hazard and sealed.

How to solve a problem like code debt?

Code debt is the most consistent type of debt that an organization will/should pay off. Developers should be encouraged to follow the scouts rule of leaving the ground a little bit cleaner than they found it. A portion of every sprint must be dedicated to refactoring. Refactoring must be built in to feature development and must be a continuous effort.

If during the efforts of refactoring, a deeper architectural flaw is exposed that needs to be addressed, then this must be done as a separate effort so as to not bloat the feature development effort.

Process & Methodologies Debt

The industry is constantly evolving processes and methodologies, along with technologies, in order to optimize productivity in people. Thus we started from traditional project driven models and paradigms like SDLC, to Agile, to Lean. Software development also has evolved in its methodology coming up with techniques and processes to improve quality, decrease defects, increase understanding and happiness within stakeholders and developers alike.

Any time a team needs to adapt to a new paradigm, there is a phase where there is actually a dip in productivity and some flux. Because there is always market pressure to deliver, sometimes ideas such as adapting to more TDD or DDD methodologies, or to move more towards a DevSecOps model of working is often postponed or dismissed as ‘too hard’. And this leads to the last of the quarter of technical debt.

This is probably the most difficult to solve because, in many cases, this goes beyond just writing code differently or restructuring your application. This attempts to change peoples’ attitudes and deep-rooted biases towards a style of working. It requires a lot of management by-in, infinite amount of patience and a very clear vision about where they want to go with this.

Conclusion

In the above classification of different kinds of technical debt, except for the code debt, which could be to a certain address, addressed due to developer experience, or lack of understanding of the system, all other debts have a bearing on each other.

Legacy tech stacks lead to fundamental fissures in the architectural landscape and how they need to be supported. The more legacy and architectural debt you have, the harder it becomes to adopt new processes or use new tools. Try upgrading to frequent deploys with a monolithic application. See your engineers break into a cold sweat. Point being, you cannot address one part of your application landscape without creating an impact on the other.

Top managements across the world are hearing the T word with increasing consternation. What they need to know is, like any mess, the longer you ignore it, the harder the stains delve deep in, rendering the structure quite useless and broken at some point.

Covid 19 has given organizations the much-needed kick in the pants to hasten their long neglected digital transformation processes(aka addressing long neglected tech debt concerns), proving 2 things. 1. Organizations can transform when it is a question of pure survival. 2. They will not change until their very existence is threatened. Question is, do we need to wait until the brink of collapse before listening to the people who create our systems, or can we be smart enough to enlist them as partners in crime to respond in a more phased, structured and less obtrusive manner to answer this most pesky of all questions -