How a focus on Tech Investment can help avoid compounding interest on Tech Debt

Written by Jack Talbot, Lead Software Engineer

Tech debt is created when a decision is made in code that we know requires refactoring but the chosen implementation allows for the delivery sooner. It is the direct act of choosing to spend time in the future in order to deliver functionality now.

“We know we need to refactor X, but we need Y now, so just build Y to work with X and we’ll refactor them both into Z in the future”.

Building debt on top of debt

Just like other debt — Tech debt accrues interest:

• When the amount of effort needed to service the tech debt increases as new work is introduced or as the impact of the debt is realised.
• When the longer tech debt stays unresolved, the more impact it has on other areas of the timeline and new code.

What is Tech Investment?

Tech Investment can be thought of in two ways:

• The opposite of tech debt, i.e. the investment of time now to improve/simplify functionality in the future.
• The repayment of tech debt, i.e. the investment of time now to recover the codebase to a functionally neutral position.

Treating Tech Investment as the opposite of Tech Debt can create its own burdens such as: premature generalisation or optimisation, and can also create unused/unneeded behaviours/features.

Rather than “doing tech debt,” we should instead focus on “tech investment”- as a treatment of tech debt; through which, we can repay some of our debt and position ourselves in a more robust position moving forward. We can then prevent building debt on top of debt.

Estimating Investment Cost

There are two factors that are important when identifying the cost of tech debt:

• Impact of the debt
• Cost to resolve the debt

When tech debt is treated as a “separate project” then the tech investment is higher cost; is because the work is done in isolation. This is sometimes necessary for larger pieces (see my discussion of Bulk Investment below), but the majority of tech debt can be actioned during related project work if tracked and planned. When tech investment is included in on-going project work the investment required is often lower.

For example, to refactor an overly complex method,it might take 1 engineer 2 story points and improve the maintainability of the code.

When considered as an investment made as part of another piece of work–investment that builds on top of this part of the code– the cost may cancel itself out. The reduction in complexity from the refactor can make the work simpler. Ultimately resulting in zero overall cost but significant positive impact to the codebase and reduced cognitive load on the engineer.

Tracking Debt

When new debt is introduced, or existing debt acknowledged, it should be tracked. Tracking debt enables it to be better attacked and for compounding debt to be identified before it becomes too embedded.

Effective tracking needs to be visible to both product and technical teams so they can acknowledge the work during unpack of new features and also support and prioritise investment in those areas when needed.

In my team at FanDuel, we are proposing an on-going, engineering led, tech debt register be maintained and utilised to better plan for and monitor debt and the appropriate investment required to handle it.

All engineers within the team should be supported in raising tech debt, and the record should describe the following:

Category

• Code Debt — an area of the codebase requires investment to improve, reduce complexity etc.
• Test Debt — test coverage is missing, tests are flaky etc.
• Architecture Debt — the design structure is not performant, too much is being done by a service, doesn’t fit design decisions etc.
• Infrastructure Debt — provisioned hardware is not appropriate, database versions are outdated etc.
• Documentation Debt — missing, incorrect or incomplete documentation etc.

Cause

• Intentional — we accepted this would require additional work later but made a decision to accept it for a faster or simpler delivery now
• Accidental — incorrect assumptions or decisions led to the situation we are in, but this needs to be addressed
• Bit Rot — on-going development has resulted in decay of a code block’s complexity or no longer fit for purpose architecture etc.

Impact/Risk

• High — a lack of investment could result in bugs, unpredictable behaviour, service failure etc.
• Medium — a lack of investment could cause a future project to fail or overrun, additional work to become overly complex and result in bugs
• Low — something we should address which could develop further if left, but unlikely to add additional risk elsewhere

Tracking Tech Debt at FanDuel

At FanDuel we utilise SonarCloud and CodeScene for the management of tech debt; these tools provide support in two areas:

• Up-front identification of technical code debt that requires analysis and potentially investment
• On-going monitoring of new code and helping to prevent bit rot within the codebase due to evolving code

There are areas of the codebase that currently score poorly in both of these tools; with a large amount of complexity identified in some flows. This is not a surprise to developers working on these services, who have also noted this complexity, and regard it as a contributing factor to both bit rot and design debt.

Next Steps

SonarCloud & CodeScene only go so far. They make tech debt visible, but as stated earlier, to be effective, tracking needs to make debt visible in the right place (the backlog), at the right time (refinement) and to the right people (technology and product). Integration between these tools and our work tracking system (Jira) would enable this by increasing the value of these tools and allowing the team to more effectively act on the debt they identify.

Step Size

Based on the next step recommendation, we recently proposed a trial of Step Size. With this tool engineers can raise code debt and related debt directly to Jira while working in the codebase. Through Jira integrations these can then be added to the team’s backlog for inclusion in sprint planning and tracking.

Even better, Step Size supports voting on tech debt, so engineers can prioritise technical investment they feel will have the most impact on their day-to-day.

On-going Investment

Debt Investment done as part of team maintenance and code ownership is important in order to maintain top knowledge of technical debt. To stay on top of technical debt engineers should utilise the following:

• Low cost investment at the point of discovery. Investment can be made at the point the debt was identified without significant impact to the work the engineer was doing when they noticed it.
• Technical investment ahead of upcoming project work identified as part of unpack. This tackles known complexity and can act to reduce the story complexity of the new work when the development begins.
• Technical Investment that engineers feel needs to be addressed now to improve the general health of the codebase.This deals with general issues raised by engineers, that while not directly related to upcoming work will likely be in areas of the codebase that are pivotal to several feature flows.

Bulk Investment

When the investment required spans large areas of the codebase and cannot be done within one sprint, the debt may need to be targeted as its own project rather than done as individual tickets within the normal technical investment budget.

This type of tech investment typically relates to large refactors, re-architectures or re-platforming of the codebase, such as breaking up a service into smaller microservices.

These projects should be developed with stakeholders, and the value presented by the engineering team in order to help prioritise and budget for this work. Typically they should not be treated as part of the same technical investment budget that teams have within their standard sprint planning as they can often present issues when worked on alongside feature work.

For example, if a large section of the code base is undergoing refactor while feature work is also being developed in the same area, it can result in either the new refactor missing the new feature work or over complicating the new feature work as it is developed incorrectly for the refactor. Meaning, it will all Incur technical debt from the start.

Next Steps

As we move forward with our tech investment projects within our team we will regularly reviewthe impact of each of the above approaches and make tech debt and investment part of a sprint goals, retros and team strategy.

As part of that review, once we’ve completed our trial of some of the approaches above, we will write a follow up detailing what we’ve learned and discovered including what we adopted, what we discarded and new areas we’re starting to focus on as we move forward.

FanDuel note: We are always looking for talented people to join us. If you are interested in working in an environment with great culture, great benefits, modern tech stack and serious employee-growth opportunities, don’t forget to check out our careers page.

How a focus on Tech Investment can help avoid compounding interest on Tech Debt was originally published in FanDuel Life on Medium, where people are continuing the conversation by highlighting and responding to this story.