Pay Down Technical Debt
“Move fast and break things.”
– Mark Zuckerberg
What Is Technical Debt
As veterans of both startups and technology companies, we know a fair bit about the downside of technical debt. It arises because the early days of projects are foundational but also hurried. And over time, a variety of challenges pile on to increase technical debt. It’s not unlike using a credit card – if you run up your bill and pay the minimum amount, your balance either remains at the same level or perhaps even grows. Let that spiral too long, and it takes years to unwind. Technical debt is quite similar. In this article, we explain the various types of technical debt, their impact, and how you can pay down technical debt.
Types of Technical Debt
Although there are numerous more types of technical debt, we’ll focus on three pillars of business and walk you through a few examples. Our list is by no means exhaustive, but it should give you an idea of what you should be looking for.
Your team undoubtedly brings you additional technical debt. It’s not their fault directly, but here are some examples…
Hiring & Onboarding
When you’re hiring, your process allows gaps between expectations and reality. Perhaps you hired someone underqualified hoping to groom them into a position. Or perhaps their skills were exaggerated on their resume (it’s happened to us…). And if your hiring process didn’t catch a problem, your employee onboarding process can also introduce or exacerbate the issue. You want to hire and retain employees who solve your actual technical problems. When there’s a discrepancy, you wind up with technical debt.
We’ve written at length about Single Points of Failure (SPOFs). We often see people who are SPOFs in companies we talk to — you know, the developer who started writing the application a decade ago, knows how everything works, knows how to fix anything that comes up, but has never documented anything (or at least in many years).
Another form of technical debt is a by-product of hiring and onboarding – skill gaps. “We need someone who knows SQL” or “I wish Susan was better at making user interfaces” are symptoms of missing skills on your team. Perhaps it’s too expensive to hire another person or you can’t justify the staffing for a small need.
Similar to SPOFs are those team members who can do it all but you have to catch them when they’re available: Demand > Supply. They’re experts at troubleshooting and break/fix, but they’re heads-down developing that new system, not working on the old one.
Outside vendors can also fit into some of these previous types of technical debt, or they could be underutilized because you don’t have time to manage them.
The second pillar of technical debt, the most obvious one, is the area of your technology.
Do you have old servers or computers hanging around? Not only are they at risk of hardware failure, but there are potential security threats, upgrade dead-ends, and incompatibilities with new configurations.
When you first built that custom billing application, you made some basic assumptions that hold you back today. It’s a pain that you live with in every billing cycle. That’s backend technical debt.
You have an amazing database, filled with useful customer data, but users regularly have to ask developers to write custom reports to get what they need. A few tweaks to the interface could empower them to build their own.
We frequently run into systems with dirty data – duplicated addresses, missing columns, fields that should be required but aren’t.
Cyberthreats grow daily. It seems that each week, there’s a major breach or a ransomware attack in the news. The hackers’ toolbox gets more sophisticated, systems grow more complex, and more systems are exposed.
Even if your organization’s servers rarely bog down or crash, you need monitoring to ensure the best user/customer experience. But if there are uptime issues, that’s definitely a debt concern!
One of the most ignored areas of technical debt is process. In many cases, the company hires another person or throws more hardware at a problem that really originated from poor process.
A good Software Development Life Cycle (SDLC) has clearly defined processes for gathering requirements, planning, architecture, development, testing, and deployment. If your software development process sucks, your system probably follows suit.
If your team includes cowboys who shoot (code) first and ask questions later, you may have more technical debt than you know. Using modern platforms, design patterns, and coding frameworks should not be a luxury. It enables easier onboarding, higher quality code, and better collaboration. Without it, you get little of that benefit.
I was reduced to tears at one point in my career by a product manager insisting that our company didn’t need to test our (accounting!) software – that users would do it. Quality assurance is an upfront investment, not a technical debt, if you want to survive in the long term. If you want to learn more, we’ve written about the importance of building out test frameworks.
Automating software delivery is challenging but effective if done properly. We’re true believers in CI/CD pipelines. We’ve seen cases where CI/CD setups were assembled with chewing gum and bailing wire, making release days a nightmare for everyone…including users.
Document lasted updated March 1, 2015… Perhaps your SDLC practice was better a few years ago, and that whip-smart lead developer bolted for greener pastures. And then no one jumped in to keep things up to date. And it only got worse. Six years later, you need to share that documentation with the client, only to see that last update date. Ouch. Documentation is organic, and it needs care & feeding throughout the SDLC.
Effects of Technical Debt
We’ve hinted at some of the problems created by technical debt, but we’ll drill down on four specific ways it negatively impacts your organization.
Technical debt is a residual tax on the organization. Things take longer and consume more resources (energy, money) in the long run. Everyone has to work harder just to get by.
In many cases, technical debt lives as “unknown unknowns”. But in many more cases, they’re known – which makes them less excusable. If you owned a restaurant and never cleaned out the refrigerator, you’d eventually get shut down by the health department, if you didn’t run out of customers first.
Downtime, poor quality, weak documentation… Customers will head for the exits if they feel that business risk bubbling in the cauldron. Software and services are growing more competitive.
Speaking of heading for the exits, employees don’t like working in stressful environments either. And when they leave, guess what – more technical debt via tribal knowledge departing.
How to Pay Down Technical Debt
Make a list and check it twice. Talk to your team(s) to find areas they are concerned about. Ask them about personnel, technology, and process issues. As you catalog them, assign a few scores to them: impact on the business, effort to remedy, and priority. We like 0-10 ratings (10 being highest), combining the scores to a total you can tackle in order (easy to remedy, high impact, most important in timing).
In general, that effort score is inversely proportionate to cost. Although doing easy stuff can move the needle, not everything is easy. Some technical debt will take time and money to remedy. As the old commercial used to say, “you can pay me now, or you can pay me later.” As a reminder, technical debt is an ongoing tax, but it eventually has a remediation price tag. You’re simply putting it off. Invest in tackling technical debt to remove the tax and settle the bill sooner.
List, prioritize, DO! Let your team in on the goal – it’s in the company’s best interest, but it’s also an investment in the team. They’ll be more inclined to help solve the problems if they know why. It may hurt a little at the beginning (e.g., peeling off a bandage), but the pain becomes healing. For example, if your organization doesn’t use a CI/CD pipeline, beginning automation can be awkward. But once it is rolling, processing should operate smoothly.
It’s good to know where you were and where you have landed. If you’re tackling your prioritized list of technical debts, you’ll want some metrics to go with them. How is employee morale (before & after)? What is NPS score with customers (before & after)? What is the impact on revenue and expenses? Is production better?
Ouch…You’ll Never Be Technical Debt Free
Utopian businesses don’t have technical debt. The reality is it never ends. We make choices between fast & easy or well-architected & challenging. We’ve worked on extremely successful products and projects that had many bodies buried underneath. The employees spent countless hours working around known, inconvenient technical issues. “Well, it works.” It works until it doesn’t. It works until the SPOF leaves, It works until the compliance officer finds out about it. These issues bubble under until they boil over. But that’s not to say you can’t always strive to improve. It’s better business to pay down technical debt, employ better practices over time, and minimize adding to the deficit.