How to balance technical debt with development to avoid unnecessary optimization and debugging.
Daniel McGrath is the Director of Engineering at Truebill, the DC-based fintech startup famous for canceling unwanted subscriptions. In this three-part series, we interview him about how they balance technical debt and product development while building a popular consumer tech product with a growing user-base.
- In Part I, we talk about what technical debt is and how you can tackle it (or better yet – avoid it). Daniel provides tips for tech teams to pay off technical debt without getting bogged down by it.
- In Part II, we talk about how tech teams can avoid wasting time on premature optimization. Daniel shares advice for tech leaders to strike the right balance between perfection and delivery, without sacrificing the quality of the end-product.
- In Part III, we focus on debugging, and how engineering team leaders can hire and structure their teams to resolve bugs and outages fast.
The conversation below has been edited for length and content.
How do you balance technical debt and product development?
The first thing that comes to mind when hearing the phrase “technical debt” is that it gets thrown around too much. It’s one of the broadest terms in the industry and can have a thousand different meanings:
- Code you don’t touch anymore? Technical debt.
- Systems that are slow every so often? Technical debt.
- An old version of a library you’re using? Technical debt.
Of course, some of these problems are more important than others, so it pays to think of technical debt at a more granular level. I always remind myself “not all technical debt is urgent.”
You can’t afford to ignore technical debt, but you can’t put it ahead of product and delivery, either.
So how can your team tackle technical debt without getting sidetracked? How do you balance paying off technical debt with shipping new features?
Start by defining technical debt.
Like many aspects of technical strategy and product development, it helps to make sure you’re thinking about technical debt the right way. Rather than simply asking where we have technical debt and how to fix it, I try to understand the goal: where are we trying to get to, and what is currently going to slow us down in getting there?
Say we’re trying to build a fancy new feature. We could dedicate 100 percent of our time to building that feature, or we could carve out a week ahead of time to upgrade some stale dependencies or refactor some related code. What’s the best option?
The best analogy I’ve heard in the past is: if you think about building software like cutting down a tree, are you going to try and do it with a dull ax? Taking the time before you start on a large initiative to improve your tooling can often help you get to the finish line faster than if you jumped in head-first.
In other words, it’s about assessing the impact. I try to approach each task or problem we face by asking key questions. Is this taking a lot of time away from our developers? Is it a problem that’s actually preventing us from meeting a business demand?
It’s impossible to make progress on anything you don’t measure.
Whatever your definition of technical debt is – it’s important to have that cataloged somewhere. Having common vernacular lets you identify where technical debt is blocking progress.
A recent example: there’s a library we depend on that was a few major versions behind. Everything we built was integrating into a doomed piece of software. We’d spend extra developer time trying to find documentation for this older version of the software.
To help us avoid situations like that, we do retrospectives as an engineering team once every quarter, as well as after we launch new features. We always ask these questions during retrospectives:
- What went really well?
- What could we have done better?
- Ideas for the future. What do we wish we had thought about?
When we talk about what we could have done better, that’s when technical debt often comes up. We take the time to reflect on where we spent a lot of effort for relatively little gain, and discuss ways we can improve that for the next time. We start talking about how much time we spent on something like trying to integrate with a library.
There are other avenues for these things to come up, such as in post-mortems following a production issue. The ideal outcome of a post-mortem is that something that bit us can never bite us again, which often leads to identifying and remediating technical debt.
Join the hatchpad to get notified and get more advice from local developers and tech team leaders.
