Can you really remove technical debt?

By: Saket Saith & Prasad Edlabadkar

In software development, technical debt is the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Analogous with monetary debt, if technical debt is not repaid, it can accumulate "interest", making it harder to implement changes. - Wikipedia

We all experience the great challenge called Technical Debt. It is a result of tactical decisions that we make somewhat reluctantly to address challenging market conditions with a promise that we will remediate them at the first available opportunity with strategic long term solution. However, that opportunity seldom arises and we end up accumulating more and more technical debt. Why? Because remediating technical debt is often out-prioritised by revenue generating growth initiatives or other pressing regulatory, compliance or audit issues. Consequently, there is no time, money, or capacity to fix it. Business is continuously pushing IT teams for new features and capabilities with same development capacity. Typical development teams are forced to prioritise these new features over technical debt remediation. What does it mean? We create more technical debt in every release. Because we don't adhere to architecture strategy, changes becomes more complex and time consuming resulting in significantly more cost and reduced speed of delivery for even simple changes. Have you ever wondered how are you going to ever remove the technical debt as you don't see too many options without major disruption or uncomfortable discussions? If yes, you are not alone.?

In this paper, we try to provide a view on how you can successfully resolve technical debt in a more practical way. It's not easy but it is?definitely possible. Let's dive in.

To begin with, we think the industry overplays the size of the issue because each stakeholder has a slightly different objective or even a hidden agenda. Who are these stakeholders? Everyone. Everyone in the organisation is a stakeholder. Right from a junior developer all the way upto the CEO. With different agenda and KPIs, everyone is pulled into different directions and priorities that prevent technical debt from ever being picked up as a priority item. We know it's very difficult, if not impossible, to align everybody in the organisation to the same goal. Does this mean we can never ever get rid of technical debt?

Not really. We believe technical debt can be managed and remediated effectively if?all of?the below conditions are met;

1. Your organisational objectives are well aligned
2. You set aside capital to incrementally reduce technical debt?
3. You commit to introduce lesser technical debt going forward?
4. You know how to measure technical debt
5. You create the organisational will to find efficiencies in your practices

Let's look at each of them in a bit more detail.

Your organisational objectives are well aligned

The top management in every organisation is faced with challenge whether to work on new feature that business demands or work to fix technical debt to align technology landscape with strategic architecture. On the other hand, a developer believes it's "cool" to work on new features because it gives them sense of satisfaction and great visibility. However, working on technical debt remediation is considered as "cleaning someone else's mess" that doesn't add value to their profile.

It's important to understand that new feature delivery and technical debt remediation is not an either-or situation. Organisations have to set priorities for delivering new features as well as remediating technical debt. The crucial factor is to find the right balance and ratio between the two and reward both of them equally.?

Be pragmatic about technical debt. Not all debt is created equal. Technical debt, like financial debt, accumulates interest at different rates. Prioritise the remediation of items that will lead to significant interest accrual at the top of your list. This will also help you establish a “trusted partner” relationship with your stakeholders by creating a natural alignment of objectives. Be willing to deprioritise items that do not offer a significant cost-benefit advantage. This does not mean the items fall off the list. It just means they will continue to be monitored but remediated at a later point in time.

If you have developers who feel rewarded only by delivering new features, then you have not set their objectives right. Tech debt remediation can be very cool in itself. It requires lot of creativity and out of the box thinking. It is a much more complex problem to solve than to write new code from scratch. There will be takers, but you need to inspire those behaviours right from the top. Below are some examples of how you may try to achieve this.

• Make tech debt remediation “everyone’s business” by defining business friendly KPIs that can be directly or indirectly attributable to tech debt. Some examples include reducing the unit cost of incremental change or accelerating delivery time from ideation to realisation
• Add tech debt remediation as one of the the KPIs in top level objective which would make its way to a developer's KPI
• Create a platform to showcase tech debt remediation and the benefit it provides to the business and invite developers to present. These may be Town Hall presentations, TED talks, brownbag sessions.
• Create a culture of appreciation and reward for technical debt remediation.

You set aside capital to incrementally reduce technical debt?

Any work requires funds. Funds in terms of developer capacity, testing, infrastructure and operations. Often, funding is allocated for building new features (including regulatory requirements) and for application maintenance in production. So key questions executives should think about is, how do teams find funding / capacity to remove technical debt? This can be achieved by allocating a portion of funds solely for removing technical debt. This is the tricky part. It is a difficult conversation with the business to acquire such funding as there isn't any "new value" that IT would deliver to them.

We recommend a two-pronged approach to solve this. Firstly, get smart about creating new delivery capacity. There is often plenty of opportunity to remove inefficiencies in the DevOps process, thereby reducing the cost of incremental change. Business stakeholders will be happy to let you re-invest these savings into tech debt remediation.

Secondly, the CEO has to understand technical debt and then set the direction along with the CxO team for remediation. As technology is now an integral part of the business, business teams need to know the implications of accumulating technical debt. For this, IT teams need to spend extra effort to present implications of technical debt and benefits of remediation to business teams using their vocabulary. If done correctly, it is relatively easy to secure funding for technical debt remediation.?

You commit to introduce lesser technical debt going forward

It is impractical to assume that teams would never introduce technical debt even after the architecture team has defined a robust strategy and a scalable architecture. Business and market forces will inevitably drive teams to make tactical decisions that don't align with strategic vision. Most of the time, strategic solutions are perceived to be slower because of missing foundation components that needs extra effort building the first time, lack of skills and lack of motive to change status-quo etc. It is true that it's often faster to make small changes to an existing system (though not optimal) than delivering them using strategic architecture, but that is a very short-term benefit that quickly erodes the long-term value of your systems. This is where teams create technical debt by enhancing a system that is expected to be decommissioned without articulating the duplication of effort and erosion of productive capacity this will cause.?

It is the responsibility of technical leaders and executives to motivate and push the teams to adopt more strategic ways of implementing solution to avoid building technical debt as much as possible. One way to achieve this is by making it easier to deliver a solution using strategic architecture and making it difficult to do the same using legacy architecture. Governance forums and introducing additional control points for legacy technology can be effective tools in such cases. It is important to note that this will lead to initial outrage in the teams as you challenge the status-quo. However, over a period of time, teams will start moving to the strategic solution as it would enable them avoid control gates that cause delay in the delivery process.

We have also encountered situations where the strategic solution has not been holistically fleshed out, resulting in poor developer experience. To be considered fully ready, your strategic solution must account for not just the technical nuances, but also the process and people implications before being released to the broader developer population. Developers are under considerable delivery pressure and should not have to jump through too many hoops to do things right.

An effective approach we have used here is to make building things right the most enjoyable experience for the developer – let us call it the motorway experience that ensures smooth and speedy rides from point A (ideation) to B (realisation). Developers also have the choice to choose other experiences such as gravel road, rocky road, or build your own road. By offering this choice, we notice a marked improvement in the quality of decision making and the gradual development of a culture of doing things right the first time.

You know how to measure technical debt

To eliminate technical debt, organisations need to understand how to measure it in the first place. Not every tactical decision is expensive at the face value. However, if there are lot of small tactical decisions, collectively they may add up to significant amount of technical debt that may prove to be significantly expensive to remediate.

Thus, it is important to implement methods to measure technical and financial impact of technical debt. One of the easy ways is to implement a process where each tactical decision is weighed against combination of effort / cost required to remediate and loss of business if tactical solution wasn't implemented. The cost of a tactical solution should comprise not just the cost of delivery, but also the cost of subsequent remediation – also known as IOUs. Doing so lays bare the actual total cost of the tactical solution and corrects the perception that it is a cheaper or faster alternative. In most cases, you can also add the opportunity cost of diverting costly delivery resources to tactical solution building instead of focusing on other growth initiatives.

If loss of business is significantly higher than the cost of remediation, it's a simple ask to business to allocate funds to remediate technical debt and continue with the tactical decision. If it's the other way round, you should try and convince the business to implement the solution in the strategic way as it will result in lower overall cost. In some cases, loss of business may not be measured in financial numbers but in terms of intangible value such as customer satisfaction index, market reputation, regulatory requirements. In such cases, a case by case assessment is required to understand impact of technical debt and its remediation plan.

Each technical debt item by itself is individually small and will not attract the right level of attention if discussed alone. But looking at overall numbers inevitably paints the true picture. Keeping track of all approved tactical decisions and providing a consolidated view of accumulated technical debt and remediation plans to CIOs and business will allow them to initiate meaningful and factual discussions to lower these numbers. As an example from previous experience, when we presented the total cost of tactical decisions approved in a single year as a percentage of overall IT budget, the numbers were eye-watering – almost equaling total IT spend.

You create the organisational will to find efficiencies in your existing practices

Over number of years, organisations have established and matured a set of software delivery practices that teams are comfortable with. However, in our experience, these may not be most efficient ones especially with rise of DevOps toolchains and practices. These inefficiencies exists due to organic changes to processes and varied skillset / experience of team members.?

While these practices will vary from organisation to organisation, few examples may include;

• Move to automated build and release so save effort spent on coordination activities.
• Legacy applications have "a specific" style and pattern of implementing changes that teams may be following for years. You will need to challenge the status-quo to work out new and efficient ways implementing changes that allows faster and simpler delivery.?
• Move to smarter testing. It takes lot of effort to test any change in legacy application because of old technology stack and size of the application. Optimising test strategy can help get some capacity back.
• Consider using?Strangler pattern?to break away from monolithic applications to micro services application that will help you reduce the scope of change and testing.

While this is a very limited list, organisations need to find opportunities to improve these practices that will free up additional capacity and create better developer experience. Then, instead of investing this capacity in building new features, invest it in technical debt remediation. If done right, tech debt removal is not only possible, but almost certain.?

These are a lot of conditions and definitely are not easy to implement. You will need to work on all of them if technical debt is challenge for your organisation. But if you’re willing,?it can be done.