- Are your costs to maintain systems increasing?
- Do you find it challenging to hire people to work on your project?
- Does it take longer now to add new features than it did a year ago?
If the answers are positive, this could mean that your organization's technical debt is growing and hamper your company's agility.
Meet Jim. Jim is a software engineer. One day, a project manager approaches him with a task: "Here is a new project brief. Could you please estimate it?" Jim evaluated the project to be done in six months. But for Jim's manager, half a year wasn't an option as he wanted to finish the project within four months. Jim had no choice but to agree. A month later, the project manager asks Jim to add a new feature to a system. Jim suggested two options: do everything proper but longer or faster but deficient. Needless to say, that PM decided to go with the quicker solution. That was the moment when Jim made a deal with a devil and took a technical debt.
What is technical debt?
The Software Engineering Institute at Carnegie Mellon University defines technical debt as "the tradeoff between the short-term benefit of rapid delivery and long-term value."
Another perspective comes from Atlassian: "technical debt is the difference between what was promised and delivered." In other words, it's prioritizing speed and delivery over a perfect code.
Research by Stripe suggests that "the average developer spends more than 17 hours a week dealing with maintenance issues, such as debugging and refactoring".
Let's go back to Jim. He had to add new features to a software system, and at that moment, he had two options: either opt for a faster but compromised solution or take more time to finish the task but later rework the product in terms of resources and time.
Technical debt works the same way as financial debt. If you don't repay the loan, it continues to compound until the loan principal ends up being much higher than the original amount.
The bottom line is that the longer you ignore technical debt, the more software entropy can occur.
Technical debt is not that bad. Almost every business has some degree of it. After all, the end-users do not notice the technical debt, so the companies often overlook it. For some time, this does not affect the functionality and quality of the product. But having tech debt can turn against your business if you won't keep the "we'll fix it later" promise, get back to it later and do it properly.
Causes of Technical Debt
It’s acceptable for growing companies that need to release a new version of a product as soon as possible to test the waters, collect user feedback or analyze market needs.
99 % of projects have a certain amount of technical debt. The rest of them have not been released yet.
But you need to be careful about software technical debt and know how to manage it; otherwise, it can lead to some negative consequences. The more tech debt accumulates during the software development process, the more it can negatively affect the business and slow down the next release. So what causes technical debt?
- Business pressure to deliver the project to the customer earlier than it was estimated.
- Poor planning and prioritization of product backlogs when design and development start without proper requirements analysis.
- Poorly or hastily written code, when each developer writes code as they see it without adhering to specific coding standards.
- Legacy issues continue to generate a cost for the business.
- Lack of technical documentation. Documentation doesn’t need to be comprehensive: it could be wikis, collaborative documents, or code comments. Well-written and structured documentation allows developers to understand how a system works faster and speed up building new things.
- Lack of automated tests, including unit tests and end-to-end tests. Often, developers neglect to create automated tests until the end of the project. As a result, it’s harder to fix bugs and deploy changes that won’t break the build.
How to manage technical debt?
In a rapidly changing world, it is impossible to create a perfect product. The product teams should accept that there are no ideal products; there are under-analyzed ones. No matter how intelligent and talented team members are, a problem can always arise.
To properly register this debt, it is better to break it down into sources of origin, for example:
- versions of libraries and applications used;
- security problems;
- architecture errors;
- potential places for code improvement;
- warnings from compilers, interpreters and runtime platforms.
Technical debt isn’t something that can be effectively dealt with once and for all. Based on our experience, we suggest five ways to manage tech debt:
Refactor your code
Refactoring is a systematic process of optimizing code and improving the internal structure without creating new functionality. In other words, refactoring is transforming a mess into a clean code without altering its external behavior.
Refactoring doesn’t mean adding new functionality, rewriting code, or fixing bugs. Refactoring aims to transform dirty code to reduce the overall technical debt and make your code more efficient and maintainable.
Measure technical debt
Technical debt in software engineering is difficult to measure - there’s no single metric to do it. It would help if you created metrics that make it easy to track technical debt. These metrics are specific to each project. We suggest tracking the impact of technical debt using business metrics, namely:
- Cycle time: the length of time it takes to finish the task. The average cycle time shows how your developers perform from the first commit to the finish line.
- Your current situation: use tools such as SonarQube and Coverity to measure the current state of your software technical debt and technical debt ratio (TDR). The TDR is a proportion between the price you pay to fix a software system (remediation cost) to the price you pay to assemble a new one (development cost). High TDR scores mean that software is in a deplorable state of quality.
- Developer happiness: let’s be frank, if your developers are increasingly annoyed while working on a project, this could mean that there’s higher-tech debt in the system.
- The number of bugs: after each iteration, we measure how many serious bugs are left unfixed. It allows us to plan bugs fixing activities for the next iteration. We also track the amount of opened bugs vs. the number of closed bugs. It allows us to be clear of whether our team is moving in the right direction regarding code quality.
Use Pareto Principle
If you don't know how much time you should dedicate to evaluating existing technical debt per iteration, we suggest using the Pareto Principle. Assign 20% of your engineering activities to technical debt and 80% to daily tasks. In this way, the majority of the time, your team will devote to the main functions and manage the technical debt effectively.
Remember about unit tests
Writing and conducting unit tests more frequently is a way to eliminate regression bugs and recover from technical debt. With unit tests, your development team will improve the code quality, identify bugs more efficiently, and automate the testing process.
Treat technical debt as part of your business strategy
Research by Gartner says that companies that have a strategy for technical debt will ship 50% faster.
Embed technical debt into your project roadmap. It would help if you had a strategy on how much time you’ll spend paying off tech debt: fixing bugs, reviewing code, and reducing the overall debt to build a more resilient product.
Agree with your development team on how much time you want to devote to managing technical debt. For instance, you might prefer your team focusing on the health of the codebase each sprint or quarterly. Alternatively, you might decide on delivering new features to be the first on the market, then perhaps growing technical debt may be the right decision for you. Establish a clear definition of done in your team, including quality metrics.
Is technical debt that bad?
Yes and no. We are used to considering software technical debt as something scary and unacceptable. In a perfect world, it is. But the reality is that tech debt is part of every digital project. Technical debt is like credit cards: sometimes, they are helpful and come in handy. They allow you to get something faster than you could without them.
"If you're not embarrassed by the first version of your product, you've launched too late." Reid Hoffman
According to Martin Fowler’s technical debt quadrant, it is necessary not to define whether technical debt exists but rather to learn how to identify it.
- Deliberate & Reckless: you know that you are making a design decision that will inevitably create technical debt. It's a rarely practiced strategy. The development team feels the business pressure to deliver products faster knowingly violated best practices.
- Deliberate & Prudent: "acting with or showing care and thought for the future." This quadrant is about being aware of taking a technical debt.
- Inadvertent & Reckless: "things you really should have known but didn't." A team with industry knowledge should be able to avoid this type of tech debt.
- Inadvertent & Prudent: when you are doing something new, you inevitably reach the point when you say: "If only I had known this before, I would have done it differently." No amount of analysis can predict what you'll learn over a software product lifetime.
- Technical debt can be your ally if you need to buy time and ship a product faster to the market.
- The best option is to avoid debt, but you are unlikely to succeed.
- Don't consider rewriting the entire system as the only viable solution.
- Tech debt decreases productivity, so try to get rid of it as quickly as possible.
- Don't confuse tech debt with a typical mess.
- Don't chase the perfect product.
Technical debt is holding you back? Let’s fix it.