Why it’s Time to Shift Left Technical Debt

Shifting left has brought massive benefits for testing, security and DevOps, but not for tech debt and issue tracking. Yet, technical debt is one of the main reasons development teams struggle or fail to deliver. 

Let’s face it – developers don’t want to work through an endless backlog of tech debt. It just sucks. Tech debt hampers productivity, which impacts morale. There’s nothing worse than slowly grinding to a halt as a team. 

In this article, we’ll answer the following questions:

• What is shifting left?
• What does it mean to shift technical debt left?
• What are the effects of not shifting technical debt left?
• How can you go about shifting technical debt left?

What is shifting left?

In general, when we say we’re “shifting left”, we’re talking about moving tasks earlier in a processes’ timeline. By doing this, we lay foundations for better code quality in the future, and avoid even greater effort to fix things later.

The concept arose back when software development was mapped out on boards with requirements on the left hand side, followed by design, coding, testing and finally delivery. 

But testing late in the development process meant finding out about problems late, too. That meant delays, costs, compromised products and unhappy people. As products or features become more concrete, it becomes harder and more time-consuming to fix them. So they moved software testing earlier in the development cycle. They shifted it left.

The practice helps teams be more proactive rather than reactive.

“Shifting left” has already transformed a range of disciplines, like…

• DevOps (e.g. devs deploy by making a docker image and pulling it into a hosting platform. Shift it left by setting up one-click deploy.)
• IT Service Management (e.g. customers reset their passwords by submitting a helpdesk request. Shift it left by building a self-serve password reset tool)
• Security (e.g. a team manually reviews software components for security risks. Shift it left by bringing in the use of automatic Software Composition Analysis tools.)
• A11y (e.g. a11y features like ARIA roles and attributes are manually reviewed. Shift it left by bringing in an a11y linter.)

So, what does shifting left mean in the context of technical debt?

Tech teams are already shifting plenty of stuff left. We can also benefit from shifting technical debt left. 

Now, technical debt is an inevitable part of the software development process. It has the potential both to harm or help, just like financial debt. Technical debt accumulates when engineers take short-cuts in order to ship faster, and often, that’s necessary. Engineers and team leaders must manage technical debt effectively to ensure the debt is repaid with minimum impact. 

When we shift technical debt left, we’re building in tools and better processes to help us track tech debt. This enables us to effectively measure it, prioritise it and ultimately fix it further down the line.

What happens when we don’t shift tech debt left?

In every sprint, we face the tradeoff between shipping new features vs paying off some tech debt. But choosing always to ship new features is unsustainable. The way the end game plays out is we eventually become technically bankrupt. That means rewriting huge chunks of code, which can take months.

But tech debt causes meta-problems that extend well beyond the engineering team. By reducing quality and increasing time to market, we’re impacting features and deadlines that marketers and salespeople need to hit their goals. Performance issues and downtime increase workloads for Customer Support, Success and Account Management.

And of course, no engineer wants to spend a tonne of time dealing with tech debt. They don’t improve at their job. They get bored. They leave. That’s rubbish for them, for the team and also for HR – it costs a bomb and can take forever* to hire new engineers.

*well it feels like it, anyway

Find out more about how tech debt impacts everybody here.

How do we shift tech debt left?

To recap, when we shift tech debt left, we’re moving tasks associated with accumulating and managing tech debt earlier in the software development life cycle. Dealing with tech debt on an ongoing basis and at the earliest possible point helps push quality upstream and avoid unruly tech debt.

The key practice involved with shifting tech debt left is creating a robust system to track tech debt. This lays the groundwork for far more straightforward prioritisation and fixing of tech debt further down the line.

Shifting left technical debt starts with tracking tech debt properly

Tech teams typically struggle with tracking tech debt effectively. This manifests itself in a few ways.

1. Issues don’t get tracked. Pretty much every developer hates the usual PM tools for tracking issues, like Jira. These tools force them to context switch constantly, breaking their flow and serving more as a distraction that keeps them from their code. 

2. Tracked issues lack detail. Flicking backwards and forwards between the issue tracker and the IDE is annoying, which makes it unlikely we’re going to properly signpost all the relevant lines and files of code.

3. Issues get forgotten about. That’s right – the graveyard of tickets gathering dust in the backlog. Most teams have one..! 

These problems all compound each other. Vague tickets make reviewing the backlog pointless. Issues don’t get tracked because the developer doesn’t think anybody will ever bother to look at them.

So what can we do?

Well, to make tracking tech debt a continuous habit, we need to make it easy for tech teams to (1) report and log problems, (2) easily add detail to them and (3) see codebase problems.

Our goals are to ensure high-quality tickets get created. We can do this by…

• Minimising context switching – this can be achieved through extensions which live in the code editor itself
• Making it easy to link specific lines of code and files to issues
• Using a tool to make issues visible from the code editor

Try checking out a game-changing tool like Stepsize. This helps engineers track technical debt directly from the editor and add codebase issues to your sprint.

This method allows you to link issues to code, get visibility on your tech debt, and collaborate with your teammates on maintenance issues without leaving your editor and switching context.

Next steps: prioritising and fixing tech debt

Now that issues are being tracked on a regular basis, we can have a meaningful strategy to prioritise and fix issues once they’ve been logged.

Now we’ve shifted our tech debt left, our next steps are to (1) create a space for your team to discuss your codebase issues and (2) integrate your tech debt work into your existing workflow.

It’s crucial to allocate a sensible tech debt budget regularly – for example, 20% of each sprint or regular refactoring sprints – so that engineers can pay back tech debt.

Getting this right is a win-win situation. You’ll avoid technical bankruptcy and ship features faster.

We’ve written about the three best tactics for fighting and preventing technical debt here.

The bottom line

The only way to fix your technical debt problem is to start shifting it left. Tracking it needs to be a continuous process that happens as early as possible in the software development lifecycle.

It’s already happened in places from security to a11y, and it’s time we shift our focus to tech debt.

When it isn’t managed well, tech debt can have a widespread and serious impact on codebase health, team morale and ultimately business prosperity. We can avoid this by adopting three core practices to shift tech debt left. These are to track tech debt issues efficiently, prioritise and fix tech debt routinely, and to use metrics to detect and shrink tech debt. 

Shifting tech debt left needs to be the next frontier of making software development efficient, reliable and enjoyable.