How to use technical debt to your advantage

managed correctly technical debt can actually boost your operations
Debt is not inherently wrong. Unsustainable debt or badly managed debt is wrong. Actually, when used appropriately, debt can enable you to achieve tomorrow’s goals today – you just need to ensure that the benefits outweigh the costs, and that you can pay back the interest in time and are able to make a profit then debt can be very useful in business.
Businesses take loans to improve their cash-flow or make acquisitions, and individuals take up loans to build or buy their homes. Similar use cases can be applied to technical debt.
Just like financial debt is justifiable, providing you can continue to service your loans to prevent your purchased asset from falling under the auctioneer’s hammer. Technical debt, managed prudently, paying off the interest before it cripples your operations, technical debt can actually boost your operations.

Using technical debt in your favour

When you take on financial debt, there is always a process to come to an agreement and define limits to how much debt individuals can and should take on, usually determined by evaluating your credit score and financial position by reviewing your records. The are a number of ways to measure technical debt and evaluate the levels of it in your tech stack, and understanding why its there.
Let’s look at a few few reasons why and how to use technical debt in your favour.

Incremental or Emergent design

Getting the perfect design on the first attempt is virtually impossible, especially with software. Requirements are fluid, changing often and usually unpredictably. So instead of investing time and resources to create a perfect design – especially in adverse circumstances – it is more prudent to start with a minimal approach, naive solution per se, to the problem, and build on it. You get to deliver the software faster, and apply the changes needed as more requirements come in.
Getting the perfect design on the first attempt is virtually impossible, especially with software. Requirements are fluid, changing often and usually unpredictably. So instead of investing time and resources to create a perfect design – especially in adverse circumstances – it is more prudent to start with a minimal approach, naive solution per se, to the problem, and build on it. You get to deliver the software faster, and apply the changes needed as more requirements come in.

How does this help?

When you develop small un-optimised features in applications and then test their value on the user base, you will be in a position to notice clear patterns of how the code should be for the particular product you’re working on. This is as opposed to trying to deploy fully built features nobody wants in the end. There’ll be technical debt – the improvements required in the application – but here you will be able to focus resources on features that the userbase actually needs, which ends up being a plus.

Defer Refactoring

Getting all future requirements of a product from the word go will be difficult – but that doesn’t mean that a project has to stall. You can still write software with minimal codes and features that work, and proceed with the project as you observe the patterns. As such, the technical debt here will enable you to defer the refactoring until the patterns have become clear enough to call for it.

How does this help?

Requirements that call for changes in the code are bound to come, and during this period it is feasible to continue with the iterations and design improvement. However, after the requirements stop and there are no more reasons to iterate the application, simply leave it in an optimised state that will enable the refactoring to be easier. i.e., ensure that when writing the code there is minimal abstraction, and transformations are simpler like with the Transformation Priority Premise (TPP) programming approach.

Leftover Technical Debt

Rather than speculate about future requirements that may or may not come to the system, you can reduce or stop resources directed to dealing with this technical debt. Simply leave it in place to operate as is, until requirements come for a better design. These future modifications will be made based on actual patterns that you have observed in the userbase or market, as opposed to speculations.

How does this help?

The focus here is on just leaving behind enough technical debt that will be required in future pattern discovery, not too much that the future design decisions become harder. So don’t go sacrificing on clean code, otherwise there will be less developers willing to work on fixes later on. The choice on which debts are worth accruing, and which are not, will be based on issues like market forces, competitive pressures, domain experience, the maturity of the team and talents involved, leadership, all through to the culture of the particular company.

Team Collaboration

In order to use technical debt to your advantage, the developer teams, as well as management involved in the product, need to be aligned. You wouldn’t want to be in a situation where the only reason why a system is working normally is because a coder keeps waking up at night to clear its cache – with the senior management not even having a clue about it. In a perfect world, this alignment would cut across the board, from skill level and discipline, to perspective on the product. However better communication amongst the team will help in aligning the intentions behind the application and code, improving the culture around it for better collaboration.