Technical Debt: The Queen Of The Engineering Inefficiency

by Trajche Nakov

6 min read

One of the most common challenges companies face is how to reduce technical debt. In this post, we'll take a look at how tech debt can be minimized or completely avoided by simply increasing collaboration between the engineering and product team.  

Technical debt can cause so much frustration and burnout to agile teams. Software engineers can be aware of the side-effects of technical debt. However, they often fail to explain to the product team why quick and easy solutions to code development are risky. 

So, instead of stabilizing the situation, the business keeps adding more features, and the amount of technical debt grows. 

For that reason, every software development team must try their best to prevent the technical debt from accumulating, so it doesn't result in the worst-case scenario, which is project halt. 

Here are my views on technical debt in agile teams, its leading causes, and tips for how to reduce it.

Let's dive in!

What is Technical Debt?

Let’s imagine that your team is working on a project but with limited resources. Eager to outrun the competition, the decision is to change the release plan and take a shortcut to complete the project on time. 

For the first few days, everything is looking fine. Until one day, you start getting negative feedback from angry users. They found a bug. 

Congratulations, you have accumulated technical debt!

Sandro Mancuso, a software craftsman & co-founder of Codurance, gives a good definition of technical debt. He says:

Technical debt is anything preventing you from developing fast.

Like in the example above, technical debt happens when a software engineering team takes shortcuts to develop a project. 

Instead of taking the optimal solution, the team opts for a fast but risky solution. In a way, technical debt is the trade-off for shipping quicker. 

As a result, software engineers end up with more work than when work was first started. Even worse, the project may end up costing more to change than to reimplement.

What Can Lead to Technical Debt?

Lack of Collaboration Between Teams

One major reason for technical debt is the lack of communication between the engineering and product team.  

In many companies, the product team is completely separated from the engineering team. You have the business people on one side defining requirements, creating roadmaps, and setting milestones. 

On the other side, you have the engineering team that has insight into the product backlog but doesn't have access to the whole picture.

Even though many companies say they're using the agile methodology, there's only a small intersection between the product and the engineering team. 

Inexperienced Team of Software Engineers

Technical debt can also be the result of an inexperienced team of software engineers. These engineers might not know how to calculate or ignore the possible consequences of technical debt. 

Although they may know they're writing bad code, they still do it, convinced that if anything goes wrong in the future, they'll come back to the code base and fix it. 

Tight Budget and Time Pressure

Tight budget and time pressure can also lead to an accumulation of technical debt. If a team is pressured to deliver fast but works with limited resources, that team might opt to take the faster short-term solution to code development. 

Code Complexity

Code complexity is another factor that can eventually lead to technical debt. Most of the time, engineering teams write complex code in a rush to deliver. If the code that you wrote happened to work at one point, it will be hard to untangle if a new feature comes in, or a bug pops up that needs to be fixed.

how to reduce technical debt in agile

How to Reduce Technical Debt

Conveying the Value of Refactoring or Code Changes to the Product Team

What engineering teams can try to do better is to learn how to convey the value of refactoring or code changes to the product team to prevent it from accumulating. 

The engineering team can't just go to the product people and say: we need to refactor quickly.

The product team will say: we have no clue what you're talking about

Instead, the tech people must learn how to reframe those issues and express the business value of refactoring or code changes. In other words, the tech team must start thinking more like a business team. 

To avoid the vicious spiral of technical debt, the product team should be educated on the cost of technical debt. The engineering team can try to calculate the possible costs of technical debt, including:

  • changing code expenses
  • engineers' salaries
  • lost revenue

Once the product team learns how incorrect requirements or rushed code can slow down development, they might learn how to collaborate more closely with the engineering team. 

One Great Way to Tell the Product Owner That Your Team Needs to Spend Time to Reduce Technical Debt

We've already established that going to the Product Owner and saying "X should be improved" and "Y is bad code" is not going to be effective. This type of tech language might be incomprehensible for people who are not developers.

One great way is to use a metaphor, as proposed by Ward Cunningham, and further expanded upon by Martin Fowler. They say that writing low-quality code is similar to incurring financial debt.

Here's how they propose the engineering team can explain the concept of technical debt to the product team:

Choosing a quick and easy solution to code development is similar to incurring financial debt. We'll get something now, but we'll have issues in the future. Just like financial debt, we have to pay interest. The bad code we opted for will slow down the development of new releases until we eventually start paying the interest, which, in our case, is refactoring the messy code. If we accumulate a significant amount of debt, we'll spend most of our time paying interest until the project comes to a halt.

Using this type of approach when explaining to the Product Owner the risk of technical debt, you might prevent technical debt from happening in the first place. The Product Owner will create a mental understanding of what technical debt is and why it's important to keep it at bay. 

Finally, I Want You to Remember That...

Technical debt happens to all teams. No company manages to avoid it 100%. But what your team can do is to keep it from spiraling out of control by avoiding it as early as possible and discussing it with the product team before it happens.

FAQs

Q: What causes technical debt?
A few things can lead to technical debt, including:
  • Lack of Collaboration Between Teams
  • Inexperienced Team of Software Engineers
  • Tight Budget and Time Pressure
  • Overly Complex Code
Q: Is technical debt bad?
Technical debt can have adverse effects in any company. If tech debt gets accumulated, the engineering team might end up with more work than when work was first started. Even worse, the project may end up costing more to change than to reimplement. The release might be postponed and you will get outrun by the competition.
Q: How do you manage technical debt?
  • Plan reasonable workloads for sprints.
  • Improve collaboration between the product and engineering team.
  • Set procedures and schedules in motion in order not to let technical debt build up.
  • Perform regular testing and code reviews.
  • Recognize the value of refactoring.
Q: How can technical debt be prevented?
One way of how technical debt can be prevented is by closer collaboration and communication between the engineering and the product team. What the engineering team can try to do better is to learn how to convey the value of refactoring or code changes to the product team to prevent it from accumulating.
Trajche Nakov
Trajche Nakov
Software Engineer

Trajche is a Senior Software Engineer with 10 years of experience in web and mobile development. His list of achievements includes working with several international startups and enterprises to help them create high-quality solutions. He enjoys mentoring fellow developers and is always willing to go the extra mile to help the team. When he's not coding, you can find him listening to tech podcasts, answering questions on Laracasts and StackOverflow, or traveling the world.

Expertise
  • JavaScript
  • PHP
  • Laravel
  • MySQL
  • Vue.js

Ready to start?

Get in touch or schedule a call.