When you are in software development mode and moving quickly towards a goal, it’s super easy to put the blinders on and go, go, go. You sense everything isn’t quite perfect but you’ll take 85% because hey it’s better than 50% and if you slow down, everyone slows down, and THEN WHAT. So that 15% of Uh-Oh just sits there, not being awesome and not getting fixed.
Well, you know what happens when something just sits there eating chips while nobody watches—it gets bigger. So you slap a bandaid on it, because easy fixes are, well…easy. But taking the easy way out for the sake of speed doesn’t just eventually slow you down, it brings you and your product progress to a screeching halt.
In its most basic form, technical debt is the gap between expectation and reality. Your company expects a certain standard of quality when it comes to software development. But when the actual state of the code base of your product doesn’t meet that standard, that’s the tech debt gap.
Technical debt can actually increase over time, even while your product progresses. And your company’s standard of quality can change over time, too. What you considered great code when you were in the garage writing the first iteration for a few hundred beta users is going to be very different when you have millions of users relying on your service.
Now, in order to determine where the gaps are, you have to get each piece of functionality to a “ready to release” state, aka “done.” To get to that point, it has to go through a simple checklist (if you’re a startup), or a more robust one (if you’re a more mature organization).
No matter how big your company is, or how you define “done,” it’s critical that the definition is standardized, well-defined, and adopted company-wide. If it is fragmented, you’ll have individual teams—or worse, individual developers—deciding when thundercats are a go. (And we all know how hard it is to herd cats.)
So, once you’ve defined the definition of done and wallpapered your office with it, it’s time to assess whether you’ve met the ready to rock standard or not. Assess with each team to see what parts need to be brought up to “code” and then estimate the amount of time required to do just that. What is missing is your technical debt.
The last part of managing your technical debt is important. You need a smart, crisp policy of how to handle it. Your best bet? Prioritize bringing up the base where it will need changes for future enhancements.
Avoid any extreme policies. And don’t put a bandaid on a gaping wound. Weak solutions = weak product.
Allocate time to fix it wisely so it doesn’t steal mojo from all of the other new feature needs.
There are six main ways technical debt accumulates. But not all technical debt is tied to the tech itself. When you understand that this invisible part of growth can’t be ignored—especially as you grow—you’re one step closer to getting ahead of it. The six ways technical debt snowballs are:
That last one is actually the number one cause of technical debt accumulation. Every time you raise the bar, the code that was written prior to that falls short. That missed reach is your tech debt. As you grow and increase expectations, until your product catches up, you’ve got debt—you can’t expect a two-person development team to reach goals meant for a much larger group effort.
Other more common scenarios occur early on when operational speed is more important than quality. We’ve all been there. A client needs something yesterday? Well, the client is always right, so which corner can we cut today to get there faster?
So even though a development team knows better, sometimes they can’t actually do better. If company culture or leadership forces shortcuts, it’s either because they don’t understand the technical debt ratio, or that they aren’t measuring it to begin with.
Not measuring? Hello, red flag. You need more support eliminating your technical debt.
et’s be honest. You will not be able to avoid technical debt if you grow. And growth is the goal, right? Right. The good news is, there are ways to minimize how much technical debt accumulates, as well as the resulting impact.
Where to start? Call us, obvs. But also, invest your time into a lot of automated tests. Make code coverage for automated unit tests a top priority for your development teams. Why is this piece so important? Because if you need to rewrite a code base, and you have unit tests for your whole application—including that area of code specifically—you can proceed with confidence knowing that whatever changes you make won’t break anything.
The reality is that most companies who have not invested in good automated tests either don’t refactor much or are afraid to deal with technical debt. It’s the head-in-the-sand approach. Cute, right? Nope. In fact, the chances that it will break something important and they won’t catch it with manual testing is way too high.
From where we stand, we like to follow the Golden Rule of Technical Debt. (What? It’s a thing!)
If you know your definition of done, and you can estimate how much time is needed to pay down your technical debt fully, you have the number you need.
A good measurement tool we’ve found is to measure it in terms of full team time. So, hypothetically, if the whole team stopped everything and just worked on reducing the debt to zero, how long would it take? If your answer is around 6-9 months, you’re in good shape.
Why is 6-9 months the magic number? Because if you’re keeping time with your competitors and are pretty comparable in terms of innovation, putting that innovation on hold for six months isn’t going to break you (it might feel like it, but ride the wave, you’ll come out the other end hanging loose).
Now, if you have so much debt that putting all hands on deck still wouldn’t dig you out for three years, you’ve got a problem on your hands. To state the obvious, that is a long time and will be a big setback. Even if you only put half the team on it, that’s six years of digging (and of doubling your R&D costs).
Since existing technical debt is anything that falls short of the current quality standard that you expect from new code, it can cover anything. But usually it falls into the following categories:
It’s super important to note that automation is critical when attempting to understand and address technical debt. If your development teams do everything manually, as you scale you will need an ever-growing number of engineers to maintain and develop the code base.
The smartest, most productive teams use automation. Whatever intellectual work they’ve done is only done once—and then it is done over and over again automatically. With automation, new work is always interesting, consistency is ensured, and the team doesn’t need to hire more and more people.
A second important note is that a quality standard is hard to increase beyond a certain point. If you aim for perfect code, you won’t ever be able to release any new features. The most critical thing here is that you refrain from asking your team to deliver against a standard it has no muscles to do. Set them up for success instead by setting a standard that has an understanding of the expected speed of new feature development embedded into it.
Let’s say you’re building a house on a tight schedule and you find a buzzing wasp’s nest in one of the walls. Do you pull every contractor over to tear the wall down and get each last insect gathered up, losing precious time and missing the deadline? No, you don’t. You allocate some manpower to fixing it, while most everyone else keeps hammering away. And you make darn sure there are no more nests in the vicinity.
Similarly, you can’t go from one extreme to another when managing technical debt. Most companies unearth debt they didn’t know existed and in a panic, argue that everything has to pause while the debt is managed. For other important parts of the product process, sure, everyone in the pool. For tech debt, never.
It’s normal to have some. You’re going to be good if you measure it, create a sustainable process to pay it down, and prevent the accumulation of more debt within upcoming new features.
Still freaked out? No sweat, we’re cool as a cucumber. Call turnkey and we’ll help you kiss your tech debt goodbye.
We’re not saying tech debt management is easy or simple. But if you have a plan (we can help!), you’ll be able to manage technical debt while still pushing production. Here are a few pro tips to live by:
Tech debt might be inevitable, but it’s not an ogre hiding under the bed. In fact, when technical debt is managed correctly, it’s a sign of a growing company. (Nice work!) Just be responsible with it. Measure your tech debt and factor it into your decisions around how fast you want to develop new features.
If you have recently discovered you have technical debt, congrats. That means you have customers and you are growing. Tech debt is kind of like taxes—nobody likes paying them, but if you have to pay taxes, that must mean you have revenue. Just make a plan, so when it comes time to pay, you can handle it without breaking stride.
Still not sure if you have technical debt? Call turnkey. We’ll have a peek and set you up with a plan.
There are various kinds of technical debt, but basically, it’s the delta between your (ever-rising) standards and your code as written. Everyone has it, and those who have a plan to address it are winning.
Wrong. Don’t halt all production. Call TurnKey. We’ll help you create a plan to handle the debt you have, and avoid getting caught up in the snowball in the future.
One way is in terms of full team time. If your whole team stopped everything and just worked on reducing the debt to zero, how long would it take? If your answer is around 6-9 months, you’re in good shape. If your answer is longer than that, call TurnKey and we’ll help you keep your balance.
Here are recent articles about other exciting tech topics!
Trailblazing the Path to Wellness: An Interactive Map of US Mental Health Startups
Top 13 Examples of Offshoring: Companies that Were Successful and the Reasons Behind the Ones That Failed
Profiles of Top Healthcare VCs: Raising the Bar in Digital Health
What Made Golang so Popular?