Navigating Technical Debt: How Software Teams Can Stay Ahead

Often this technical debt is introduced with the best of intentions, or rationalised as the only way to bring a project in on time - on budget, and that makes it even more difficult to manage as you need to take a balanced approach to whether it's worth it or not. But how do we do that? How do you keep track of these little landmines and proactively manage them so they don’t cause major issues in three, six or twelve months' time?

Here is a brief overview of three things that you can do to actively manage Technical Debt.

Identifying Common Triggers for Technical Debt

There are some pretty clear triggers that you can keep an eye out for that are almost guaranteed to introduce technical debt in your system.

Shortcuts

Ever been in the position where a decision was made to “just get it done” by a deadline? That decision has likely introduced technical debt. The gap between the “better” solution and the “fast” solution chosen is your technical debt and there is a good chance you will need to come back and address it later down the line.

Scope changes

Already written some code to fulfil a function and now the scope is changing? This is another common cause of technical debt. The solution written to serve the original requirement may not be compatible with the new design. Unfortunately due to the nature of scope changes, often there is only minimal work done to accommodate the new requirement, in order to keep costs down, where more extensive work may have been the correct move architecturally.

Knowledge Gaps

This one is harder to address as it will occur naturally in the course of development with team members using new technologies and gaining experience day-to-day. Often if a team member is writing code for the first time with a new language or technology, the code written may not be the best way of approaching a problem and include issues that are unmaintainable or inefficient. These small changes can introduce tech debt in the form of rework to tidy things up or refactor later.

There are many more forms of technical debt as well, but these are just a few.

Tracking Technical Debt Early and Consistently

Tracking technical debt is the first main challenge of dealing with the issue overall. Many organisations talk about their technical debt and will try to add a user story or ticket to address it when there is no other choice – usually after it has cost tens or hundreds of thousands of dollars in lost time, rework, or working around it. The simple solution to this problem is to raise these earlier, create work tickets for them when we discover them in the first place. This sounds like a simple step, but it's often missed.

Got a code review where a sub-par approach was accepted? – Raise a tech debt ticket.

Made a decision to go with a certain technology because it was easier and faster than doing it the way the architect suggested? – Raise a tech debt ticket.

The main takeaway here is to raise the ticket when it's first encountered, and not later down the track when it's an issue.

Assigning a Cost to Technical Debt

Most technology teams will have a management meeting, status reporting mechanism, project board. These meetings are the perfect forum to talk about open work in the technical team’s backlog (and that includes your technical debt). Regardless of the channel, it's important to put a price on the technical debt. Let’s take an example:

The project team managed to get a release out last week but in the process had to compromise on authentication and instead of using the first choice of authentication technology, they went with a different one that was much faster to implement, but doesn’t support the plans to introduce social sign-in in the future (You identified this as a “shortcut” trigger for tech debt and raised a ticket for it right?). It's not urgent, social sign-ins are 6 months away, but it means when it does come around you have to rebuild the auth all over again.

This tech debt has several costs associated with it:

1. The cost of rebuilding the original Auth (Rework)
2. The cost of supporting the stop-gap technology only to have to retrain staff on the new one later. (Rework)
3. The cost of rebuilding any other enhancements that happen in that 6-month period. (Rework)
4. The cost of needing to wait longer for the social implementation while rebuild happens (Cost of delay)
5. The cost of additional regression testing during replacement (Cost of delay and Rework)

So quantify it! If it costs you $500 a day to rebuild this auth solution (and that’s being conservative) and all of the parts on top of that. That’s going to add up quickly. Now this is only the first step - see point 3 there? That’s the real insidious part, the one people don’t realise until it's too late, so highlight it.

If you put an initial rebuild cost on the feature of $10,000 (4 weeks, considering the pricing above), increase the cost of rebuilding for that item every week. Any executive team is going to look at the growing cost and realise pretty quickly that they need to address it sooner rather than later, and it will start the conversation about additional funding, resources, or reprioritisation of work.

Conclusion

This article only scratches the surface of how technical debt can be managed effectively in an organisation. If you want to know more, click the link below to register for my webinar on technical debt, coming up in December. You can also reach out to start a conversation with us, and avoid a development stalemate with your platform!

.