Technical debt: everything you need to know
Managing technology debt properly can mean the difference between a successful software project and a failed one. Ignoring or not recognizing it can lead to higher development costs and low financial returns. But what exactly is technology debt? How does it arise and what types are there? In this article, we will discuss them in more detail.
What is technical debt?
In the software industry, technical debt is a common term, sometimes referred to as tech debt, design debt or code debt. It is a catch-all term that covers everything from bugs to legacy code to missing documentation.
Technical debt is a quality gap that arises in all development and makes sustainability difficult. In the long term, it increases maintenance, operation and modification costs. It is therefore important to take explicit time to manage technical debt when developing sustainable products.
Where does the term technical debt come from?
The terminology of technical debt was coined by a software developer, Ward Cunningham, who is credited as one of the 17 authors of the Agile Manifesto and the inventor of the wiki. He first used the metaphor to explain to non-technical stakeholders at WyCash why it was necessary to budget resources for refactoring.
In doing so, he also created a new buzzword in the software community, which later became the subject of countless studies, debates and panel discussions.
Different interpretations of technical debt
The definition of technical debt has been formulated in different ways over the years. Let's take a look at some of them.
Technical debt is an instrument
Similar to the way someone takes out a loan on a property to get into the booming real estate market, tech debt is often used as a means to get ahead.
For example, Trey Huffine, founder of Gitconnected, explains his role from the perspective of a startup. He says that technical debt is any code that is added now to make a quick profit, and which requires more work to fix later.
Technical debt has consequences
Shaun McCormick's definition of technical debt focuses more on the long-term consequences. He sees technical debt as code that reduces agility as the project progresses. However, he does not use the term bad or broken code.
He suggests that real technical debt should always be intentional and never accidental.
As he says, technical debt is created when developers take shortcuts to achieve a goal faster, but at the cost of code that is harder to maintain.
As Gaminer puts it, technical debt is like taking out a loan. So you can achieve more than you would normally, but in the long run you have to pay higher costs.
Types of technical debt
Just as there are many definitions of technical debt, different experts define different categories within it.
- In 2007 Steve McConnell talked about 2 types of tech debt:
I. Intentional - It is a debt that someone takes on consciously, as a strategic asset.
II. Unintentional - This is the result of bad work and not of strategy.
- Martin Fowler took McConnell's concept further and created 4 categories:
1.Deliberate and reckless - The most common reason is that they strategically prioritise rapid delivery over a well-planned development process.
PLEASURE: The team decides it doesn't have enough time and deliberately reduces the features of the product. They don't even plan to replace them and put speed before quality. Or they reduce the time spent on coding during the project by giving less time to developers, resulting in inadequate coding.
2. Deliberate and careful - In this case, the team is aware of the technical debt it is generating, but it goes ahead anyway. The team can see the consequences from the start, and knows that it will need to review and reapply best practices when the time comes.
3.Unintentional and reckless - This is the most harmful type of technical debt. It occurs when the software development team does not apply best practices and is unaware that technical debt is accumulating. This makes it impossible to design solutions or measure the negative impact of debt.
PLEASURE: Sometimes some team members do not have the skills to write the software code. However, they are given the authority to work on it. As they code, they generate and accumulate technical debt. Because of their lack of skills, developers are unaware of the damage they are causing to the project and are unable to act prudently.
4. Unintentional and imprudent - The team then applies best practices at every step of a software development roadmap, but for some reason, a tech debt is generated that the experts can manage.
PLEASURE: In this case, a skilled team is working on the software code, but the technical debt is due to an unseen coding error. Their skills enable them to identify and pay for it.
- In 2014, a group of academics concluded that existing frameworks for categorising technical debt do not directly address the specific nature of debt.
At the same time, they rejected the categories outlined by McConnell and Fowler and suggested that technical debt should be classified according to its nature, rather than whether it is strategic or non-strategic.
According to the resulting document, published by the Software Engineering Institute under the title "Towards an Ontology of Terms on Technical Debt", there are 13 different types of technical debt. Key indicators are defined for each of these:
- Architectural debt
- Construction debt
- Code debt
- Error debt
- Planning debt
- Documentation debt
- Infrastructure debt
- Human debt
- Process debt
- Requirement debt
- Service debt
- Test automation debt
- Test debt
What could be the cause of technical debt?
There are many ways in which technical debt can accumulate during a project, let's look at some of them!
Reason #1: Lack of planning
If development starts before project design is complete to save time, it is likely that some elements will need to be revisited and reworked later.
Reason #2: External forces
This can include, for example, business pressure. Often, the market or business leaders will expect the product to be made available to the public as soon as possible, even if not all the necessary changes have been made. This is quite common in product management.
Reason #3: Ignorance
If the project manager and the project team are not aware of the technical debt, they will almost certainly face it. If they follow a process that does not take into account its consequences, they will move forward without knowing the inherent risks to the project.
Reason #4: Lack of flexibility
The inability to be flexible and change also leads to technical debt. For managers, flexibility is essential.
Reason #5: Inadequate documentation
Failure to prepare the appropriate documentation during the project will result in a technical debt that will have to be paid later.
Reason #6: Lack of cooperation
Lack of knowledge sharing within the project team affects efficiency, creating technical debt. Using online collaboration tools can help improve the exchange of key information.
Reason #7: Parallel projects
Parallel developments can also create debt, as the work needed to merge changes into a single resource requires additional energy.
Reason #8: Modification of requirements
If the requirements of a project change, this also creates technical debt.
Reason #9: Neglect of industry standards
Ignoring these is also a good example of accumulating technical debt, which will certainly need to be addressed later in the project.
Reason #10: Poor driving
Everything from lack of accountability to poor management to last-minute changes can be a cause of debt generation.
Is technical debt always bad?
To answer this question simply, technical debt is neither good nor bad. But it is debt.
Most software companies today are forced by market competition to develop and deliver in a short time. Start-ups in particular feel the weight of being able to deliver a product as quickly as possible. And this pressure is driving many product and software development teams to compromise on taking on technical debt.
Agile project management vs. waterfall model
Agile teams believe that technical debt is not inherently bad. In fact, most if not all software products have some degree of technical debt.
When you consider the amount of code teams deliver on a daily basis - especially in an agile environment where working software is the primary measure of progress - this is not a surprising statement.
However, software development teams working under the waterfall methodology and other documentation-driven frameworks do not share this approach.
Attitudes towards technical debt can vary widely, not only depending on the corporate philosophy, but also on the departments and roles involved.
How can we prevent the generation of technical debt?
As mentioned above, technical debt is not necessarily a bad thing, as it allows us to get our products to market faster than our competitors. As we get feedback, bugs can be corrected and the product improves while generating revenue for the organization.
The money generated can be used to pay off accumulated technical debt. However, it is also important to be aware that this debt can arise unexpectedly due to unrealistic time or resource constraints.
There are ways in which the project manager can avoid technical debt:
1. Let's talk about technical debt
This is key. If team members are aware of it, they are more likely to identify the pathways that lead to it. It's worth paying attention to it, for example, asking questions like, "If shortcuts are the right choice, what do we gain? What are the challenges and future implications?"
2. Allow time for treatment
Always ensure that the schedule allows time to address technical debts as soon as possible, so that the project can move forward while reducing vulnerabilities and weaknesses.
3. Use KPIs to monitor project expectations
By having KPIs on project performance or development, we can better prioritise the work of managing technical debt.
4. Continuous monitoring of technical debts
It is important that the team regularly monitors tech debt as tasks are completed and prioritises it with other tasks.
5. Have realistic goals
A sure way to accumulate technical debt is to give the team too many tasks too soon. Always try to set realistic deadlines and targets that you can meet without cutting corners and possibly accumulating technical debt.
Agile trends are gaining ground in projects and in the life of organisations. Develop your practical toolbox and gain international qualifications! Deepen your knowledge in our agile training courses!
Designabc