August 04, 2020
As an engineering leader, one of your challenges is to explain sometimes dense technical concepts to non-technical business executives. The concept of technical debt was born of that challenge, when Ward Cunningham used a financial metaphor to explain to his boss the purpose of the refactoring his team was doing – to avoid paying too much interest on a “loan.” Today, we still find ourselves trying to explain these concepts. While the concept of tech debt identifies a real challenge that software engineering teams struggle with, many engineers still disagree on the actual definition of it.
How you define software technical debt to your executive team can have serious impacts on the projects you prioritize and resource allocations.But tech debt can be very company-specific, dependent on the culture, who has a greater share of voice, and many other things. We wanted to understand the different ways people think about tech debt, so we asked VPEs from different walks of life. Understanding these different perspectives can help you come to a definition of your own that works for you and your company. Here are some of the explanations they gave us:
Good and Bad Technical Debt
At Crayon, VP of Engineering Jack Walter abides by a popular notion that there are both bad and good kinds of tech debt. With that in mind, he explains that “having joined after Crayon has already been building product for 2-3 years, there is obviously a large amount of tech debt, some good and some bad. What I try to focus on is evaluating the instances on a case-by-case basis, paying down the ‘bad’ debt that is restricting our growth, and doing our best to only take on ‘good’ debt going forward.”
Technical Debt as a Strategy for Speed
VP of Engineering Rob McDonald explains how at Zaius, tech debt is used strategically, and is intrinsically linked to the health of the business and sales organization. “Tech Debt are the things we do sub-optimally (intentionally or unintentionally) in order to accelerate our delivery. When sales are booming, we’re more likely to pay down debt since there’s (often) less urgency to have new features. When the Sales team needs a boost via feature or a product change, we incur debt to go faster.”
Balancing Technical Debt
Jellyfish’s own VP of Engineering, Eli Daniel explains the balancing act of taking on technical debt. “I think of tech debt as work that needs to happen eventually, but that we choose to put off until later in the interest of speed today. Extending the personal finance metaphor of taking out a loan to get money now, but at the cost of paying back even more later: it’s important to be thoughtful about how much debt you take on, and at what terms. On our team, we’ve been pretty disciplined all along, so we’re more in the mode of making our planned monthly mortgage payments that we knew about going in vs scrambling to get out from under crushing credit card debt. Concretely, that looks like having pragmatic discussions about how far to take things, how to balance speed of delivery today with removing the messes that will slow down innovation tomorrow, and being willing to both take the extra time to make things sustainable when it’s needed but also being willing to live with systems that aren’t yet living up to their full complete vision.”
How to Measure Technical Debt
For most engineering organizations, you’ll almost certainly want to measure it, figure out the right amount of time and resources to devote to it, and make sure your organization is allocating a proportionate amount of work to it. Until you have a clear definition of what tech debt means to your company, that may not be feasible. Above are just some common perspectives. How do you define tech debt?
