In an ideal world, you shouldn’t have to choose between quality and timely delivery, but it happens more often than you might think.
In this guide, we’ll define technical debt, illustrate the concept with some examples, and list some common types of technical debt. We’ll also walk you through how to prioritize technical debt and offer some strategies to help you minimize it.
Table of contents
- What is the definition of technical debt?
- What is an example of technical debt?
- Types of technical debt
- Deliberate vs. inadvertent technical debt
- How to prioritize technical debt
- Balancing quality vs. speed
What is the definition of technical debt?
Technical debt is an accumulation of tasks left undone during development to expedite product delivery. When there is a need to prioritize speed over quality, the product owner and development team must come to an agreement on which tasks they’ll leave incomplete for the sake of delivering the product or feature on time.
These shortcuts create debts, which may increase costs if left unresolved. The expense can come in the form of additional time and resources required for maintenance and fixing bugs, poorly performing systems, bad customer experience due to errors, etc.
What is an example of technical debt?
Here’s an example of technical debt: let’s say you need to launch a new consent block due to a change in privacy data storage regulations. You’re on a strict deadline to release the feature. As a result, the dev team doesn’t have time to adhere to the UX standards of the product, so it decides to create a pop-up as a quick fix to be compliant.
Because missing the deadline for compliance with data storage regulations can carry heavy fines, settling for the bare minimum is acceptable and the safest way forward. In this scenario, the cost of delay is higher than the cost of creating technical debt.
In this example, team would then create a technical debt task to later fix the design parameter per the product’s user experience principles and requirements.
Types of technical debt
The reasons why a product development team might opt to forgo certain tasks in favor of speedy delivery are myriad. Let’s zoom in on some common types of technical debt.
Code debt
Code debt is one of the most common types technical debt. Code debt occurs when developers take shortcuts instead of following code standards — for example, by duplicating code or hardcoding instead of fetching the content dynamically.
Design debt
Failure to follow design principles creates design debt.
A typical example of design debt is when developers fail to adapt the design to different channels, such as mobile and web. Another example is when a design is not built according to accessibility parameters.
Infrastructure debt
Outdated technology creates infrastructure debt.
For example, migrating a platform or upgrading a database to a new version can result in infrastructure debt. This is also known as maintenance debt because it pertains to keeping the product running.
Product teams do not incur infrastructure debt by choice; it is simply a fact of life during the lifecycle of a product. However, they can control how diligently they migrate to new platforms. Knowingly continuing to build new features on outdated platforms can result in a massive backlog of infrastructure debt.
Test debt
Test debt occurs when the team neglects to follow test standards during development. Some reasons for test debt include failure to write proper unit tests and failure to implement automation or regression testing before delivery.
Requirement debt
While prioritizing the product backlog, it’s important to distinguish between features that are nice to have features that are hard requirements for release.
Due to time constrains, it’s common for some nice-to-have items to be deprioritized and deferred until the next delivery. Then, in the following delivery, it’s common for something else to be prioritized higher.
Continually letting items slide to the bottom of the backlog can create requirement debt.
Documentation debt
In agile working methods, the second principle as outlined in the Agile Manifesto is working software over comprehensive documentation.
However, some documentation — for example, the solution design documentation and test summary report — is still necessary to deliver smooth-functioning products and to maintain the backlog. User stories are another example of critical documentation.
Without these resources, solving bugs and maintaining the system would be tedious. Any documentation gaps that could increase the amount of work required in the future creates documentation debt.
Process debt
When the flow is built to handle a process but changes for some reason, it creates process debt.
An example of process debt is when the deployment pipeline requires changes to include a new quality assurance process.
People debt
People debt occurs when expertise lies in the hands of few. This is especially common in big organizations with legacy systems that newer team member can’t be bothered to learn.
Another common cause of people debt is insufficient documentation. When complex systems lack thorough documentation, these processes exist only in one or a few team members’ brain, resulting in people debt.
Architecture debt
Teams incur architecture debt when they fail to build a solution according to the architectural design. This happens primarily due to tight deadlines and lack of resources. It can also occur when new developers are not properly onboarded.
Defect debt
Identified bugs that are deprioritized due to lower impact are eventually lost in the backlog.
The technical debts can create a massive black hole in the backlog. Over time it becomes impossible to manage and prioritize the backlog. It can also increase the cost of maintenance and result in poorly performing products, affecting user experience adversely.
Creating technical debt is not inherently wrong when it is intentional with a clear plan, and the importance of attaining a deadline outweighs the cost of technical debt. However, those technical debts due to ignorance, lack of knowledge, and laziness can cost more in the future and currently have no or limited value.
Deliberate vs. inadvertent technical debt
Although technical debt is always impactful, some types of debt can be riskier and more consequential than others.
Technical debt can be either deliberate or inadvertent:
- Deliberate technical debt, also known as active debt, occurs when the team consciously delays the resolution of an issue to achieve a set goal — for example, releasing a feature to be compliant or to stay ahead of the competition
- Inadvertent technical debt, also known as passive debt, happens accidentally or due to carelessness, such as choosing the wrong platform or committing errors in code
The technical debt quadrant
Martin Fowler’s technical debt quadrant breaks down deliberate vs. inadvertent technical debt further by measuring the recklessness or prudence of the tech debt:
How to avoid inadvertent technical debt
There are many reasons for inadvertent technical debt.
If the technical debt exceeds the backlog, here are some steps you can take to avoid incurring further inadvertent debts:
- Peer-review the code to ensure correct implementation according to the architectural design
- Have sub-tasks for process-related work, such as writing unit tests and documentation to set time aside to accomplish the task
- Avoid complex coding. The fewer lines of code, the easier it is to maintain. The more complex the logic, the higher the maintenance cost
- Set deadlines based on estimation, not another the way around
- Onboard new developers properly, giving them ample time to learn about the product
- Use automation instead of manual testing
- Use tools that are relevant to the product from a long-term lifecycle perspective
How to prioritize technical debt
Technical debt is inevitable in agile product development. However, if the team is aware of the debt and has a plan either to resolve or address it later, technical debt can be a valuable tool for prioritization.
Regardless of whether it’s deliberate or inadvertent, the team should strive to address tech debt as soon as it’s highlighted. The best way to prioritize the debt is to conduct a backlog refinement session for technical debt.
Evaluate and group the debt into the following categories:
- No-brainer — Tasks that are critical to keep the product running
- A worthy investment — Tasks that are worth doing because they contribute to a healthy product lifecycle — for example, upgrading the system to move away from legacy platforms
- Quick and easy wins — Easily solvable debts that can be fixed quickly. Usually, product managers assign these tasks to newbies so they can learn about the product while solving the debt
- Not worth considering — Sometimes bugs solve themselves. When preparing to upgrade or decommission a system, it might not make sense to invest the time to solve the technical debt
Categorizing your technical debt this way makes it easier to prioritize. The team should proactively:
- Set aside time to solve the debt tickets
- Define a goal and precise dates on each ticket
- Take ownership and drive the development to minimize technical debt
Balancing quality vs. speed
While working on new products and staring down deadlines and delivery dates, it‘s all too easy to ignore the technical debts your team accumulates along the way.
Understanding the cost of complexity is one of the most valuable lessons a product manager can learn. If you build complex solutions, you are building expensive, unmanageable products long-term. Complexity is also an outcome of favoring quick fixes, patches, and hardcoding over solving the code debt.
On the other hand, faster time to market, iterate, and learn is the basis of agile product development. Therefore, technical debt is inevitable and not inherently wrong.
To manage a successful product long-term, it’s essential to strike the right balance between quality and speed. Addressing your technical debt is the first step. Being open and transparent about the issue is always better than closing your eyes and hoping for the best.
The post What is technical debt? How to prioritize and avoid with examples appeared first on LogRocket Blog.
from LogRocket Blog https://ift.tt/DGk6ZKC
via Read more
