As a business owner or developer, have you been involved in a project where a simple feature change or even a bug fix has taken weeks to resolve and often brought with it other problems? That is technical debt in action. But is technical debt to be considered a code monster lurking in your system ready to terrorize you?

There are times when it is acceptable to have technical debt. However, it is just as important to recognize how to reduce technical debt for continued product health. After all, going into debt to buy a house is perfectly fine if you know how to pay the loan back at the earliest.

When is technical debt acceptable?

Technical debt is often a result of taking shortcuts during project development, mainly because of time constraints. You may feel then, that technical debt is a monster that will hinder growth. But there are a few instances where technical debt is acceptable and these are

• If the organization wants a competitive edge by releasing the product quickly. The project owner then makes a plan for refactoring the code at the earliest
• If it is a new idea, and developing a prototype to see if it will be viable in the market. This is a deliberate technical debt where speed to market takes priority rather than clean code.

Don’t fear technical debt but understand how to address it

The general belief is that technical debt is caused by poorly or hastily written code. The reality is that it is not always the case.

Going back to the house analogy to explain why technical debt is inherent in even the best-written code. It does not matter how well you have constructed your house, there will come a time when the roof will need fixing, the interiors repainted or the plumbing repaired. There is always wear and tear that comes inevitably with time.

Code can start out ticking all the boxes on quality but a component or system can slowly become more complex over time as new code is added on to introduce new functionality. These incremental changes may often be done by developers who do not completely understand the original software design. When the codebase grows and gets too complex, then technical engineers cannot possibly keep track of the ripple effect. this is called bit rot tech debt and is incurred by individual developers. Here is where refactoring or code clean-up at regular intervals is important.

It is important at this point to decide when refactoring should take place. It should not be continuous work, since it is a greater liability if more time is spent on refactoring rather than developing new functionality. Some companies add it to their regular sprints, while others set aside time every year for remediation.

Technical debt can affect different teams

Customers get annoyed when it takes too long to complete an action or if they encounter a bug and they cannot proceed. Loyal customers can leave if this happens too often.

The Customer Support Desk will see an increase in tickets and leads to an increased cost in manhours as well as lead to frustration and attrition. The frequency of code-related bugs (once a month is acceptable) and their impact on priority actions is a factor here.

Fixing quality issues can take up too much of the Developer’s time and frequent patches to the codebase will increase the technical debt. Not to mention developers leaving the team and the cost in rehiring and training.

The marketing team finds their campaign schedules affected as they wait for new features, while the development team is trying to address bug fixing.

Finally, the management team is getting bothered by the bad publicity and security problems that arise because of gaps in protection walls.

If any of these problems hold true for your organization, then technical debt is a real issue and strategies need to be in place to manage technical debt.

Strategies to deal with technical debt

There are different approaches to manage technical debt but all effective strategies will include these

1. Include metrics to keep a track of tech debt

Measuring tech debt is a good way to start, if this is done periodically, you will have a better idea of how much tech debt is costing your organization. Using the methodology below is one way of knowing the impact of your tech debt.

First, count the number of bugs or violations and find the density per 1000 lines of code (KLOC).

Second, is to categorize the severity of these issues into Low, Medium and High

Thirdly, assign numbers to these issues, an example of technical debt cost could be every medium bug fix takes 1 hour and costs $100

Only 10% of L, 20% of M and 50% of H issues will on average need to be fixed. Calculate values for each level as below

L= 10% x number of issues per KLOC

M= 20% x number of issues per KLOC

H = 50% x number of issues per KLOC

Now calculate the cost of Technical debt use this formula

Technical Debt = (L+M+H) x Cost x Time x Average Application Size

2. Not all identified “smells” are the same

Experienced developers and architects or even specific tools can be used to identify concrete issues in the source code at different stages of development such as during implementation, design or architecture.

Not all identified issues, also known as smells, are equal.  Different smells come with different interest rates. For instance, some smells you can live with i.e., they might have a low potential impact on the project, while others might have lived in the source code for years. The team might make a decision only to tackle smells with a high interest rate.

3. Adopt an API led technology approach

Refactoring a huge monolithic application is extremely difficult not just in development but also in testing process. The new approach to reducing technical debt is by breaking down a tightly coupled architecture into a number of microservices each having a single purpose and communicating with each other through APIs.  An Application Programming Interface is a software intermediary that allows different applications to communicate with each other.

By building smaller blocks of codes with clear boundary contexts means there is a lower cognitive load on developers. A decoupled microservices architecture allows for greater reuse and simplified refactoring.

A microservices architecture allows for faster release of new features to market, increases scalability and also provides the ability to optimize quickly for business functionality. Since cross-functional teams will be working on each service, this will enable faster deployment as well as quicker turn-around times when troubleshooting problems. If you have a monolithic architecture this might be the time to think smaller.

Creating technical debt is inevitable as an organization grows and its technology platforms get more advanced. It is essential though to keep your organization’s technical debt low and the first step towards that is to understand it and use appropriate strategies to control it. Consult with our tech experts who have helped many organizations to control their debt.