Table of Content
We all know the feeling of spending a Friday afternoon waiting for error-prone code to evolve into a production bug to make you suffer. You’ve tried to improve it, but then your product manager comes to you with a higher priority feature that needs to be addressed as soon as possible.
Well, the bug will have to wait for another time, maybe next week? And then, the cycle will begin anew. With each new cycle, you’re amassing what’s known as technical debt.
An article in the Information and Software Technology Journal defines technical debt as “the consequences of software development actions that intentionally or unintentionally prioritize client value and/or project constraints such as delivery deadlines, over more technical implementation and design considerations…”
There are so many small actions (and inactions) that probably contribute to tech debt. For example:
- We never updated the library because it isn’t a priority and it works fine… until it doesn’t.
- We created a temporary fix for an urgent issue that became permanent.
- We omitted tests for a new feature because of a deadline, making it harder to refactor the code later without breaking something because of the lack of tests.
Just like any other loan, the longer we postpone our tech debt the more work that has to be done in order to pay it off. Dealing with production bugs and witnessing developer frustration is what motivates us to take a more proactive approach to managing tech debt. With the ultimate goal of making it more of a priority for the company, we want to start defining our procedures.
Start simple
We want the documentation process to be simple, yet effective—something where everyone can contribute and propose solutions in a structured way that is easy to understand and communicative.
We can start with a simple table like this:
You will end up with a clean table that works as the foundation. Of course, you can start adding your own columns—the things you have seen, things you wanted to fix, etc. But it’s impossible for you to know everything about every single file in your project, which is why it’s important to get other developers involved and allow them to fill in the gaps. As you might expect, they won’t have difficulty flagging examples of technical debt in the code. After all, who knows it better than those who work with it every day?
Spread the idea
Next comes the critical step of getting your product managers involved. They will be a key piece of this process because they are the ones that decide if you work on something or just let it sit in the backlog. They deal with business requests and it could be hard for them to push those back and let developers work on something that is hard to monetize or that is not a key feature.
The solution is to make them aware of how much it costs to deal with technical debt during the development process, and how getting rid of it could save a lot of time and money. Here are some examples:
- Cleaner code makes it easier to track bugs. Remember that hard to read code you wanted to fix? When it eventually becomes a production bug, you’ll spend hours trying to understand the code, finding the issue and implementing a fix for it. Having clear code from the start makes that process easier—but if it’s just spaghetti, it could be a hard time.
- Save dev/QA time and money. It is simple math, fewer bugs means less QA time and less time trying to code a fix. Let’s see an example:
Imagine you fix a bug on one section of your application, you send it to QA, and it’s approved and deployed. Great! But a few days later, the same bug is reported on a different part of the application. And yes, it’s the exact same code you just fixed, but it was duplicated all over the place. Investing a few hours on refactoring and removing duplicated code will save you days of dev/QA cycles for the same fix over and over.
Let’s try to quantify both scenarios:
Some people might argue that it’s just a couple of hours and a few bucks, but the real value of this is when you multiply it by several weekly bugs. For example, assuming you see this scenario on a weekly basis, then it means you will save 104 hours and $6,864 per year—resources that you could be using on adding new revenue generating features instead.
- Reduce the learning curve for new developers. As new developers get into a team/project, the first challenge they will face is to get used to the code. The sooner they learn it and understand it, the sooner they can start being productive. Having a clean codebase would make it easier for them.
- Avoid developer frustration and demotivation. It’s not a secret that dealing with bugs and poor code can be frustrating for developers. If they have to deal with it on a daily basis, they can quickly burn out.
Once you get the PM on board, you can improve your base table and add backlog related details.
Make it happen
After the previous steps, you will have something more robust and similar to a backlog. So you can roll up your sleeves with your PM to start creating the tickets and prioritizing them into the backlog. Here are some useful tips:
- It’s important to tag or differentiate them somehow, otherwise they can easily get lost and sit in the backlog forever.
- Prioritize them. Add estimates and define estimated dates for when they’re going to be executed.
- Make sure to keep it up to date. Keep checking that the tickets are actually being processed and not pushed back. Ideally, you can schedule a recurring reminder to check up on tech debt tickets.
- Define some guidelines about how to report tech debt, that way you can help make sure that the developer has clear instructions on how to report new tech debt and keep the backlog clean.
Great job! Just like that, tech debt is now part of your regular backlog, everyone is aware of its existence and tickets can be pulled into a sprint and assigned to developers.
Conclusions
Tech debt is present in every software project. But most people tend to just ignore it, either because it can’t be monetized or because they don’t give it the importance it deserves. But it’s the team’s responsibility to talk about it, to make it visible to everyone, and most importantly to demonstrate the risk and negative impact that it can have on projects and developer motivation.
This is not a one-time exercise. Creating the backlog is just the base for it, but then everyone has to continue working to keep it updated and make this process part of the daily routine.
It shouldn’t be a hard or painful process as long as everyone gets involved and remains committed to it. If you make it part of your regular development process you’ll quickly see the benefits of prioritizing tech debt.
Top comments (0)