What Is Technical Debt, And How Do We Control It?

Veröffentlicht am - Letze Bearbeitung am

Most people view debt negatively, something that is owed and must be paid back as soon as possible. Coined by Wiki inventor Ward Cunningham, 'technical debt' refers to the compromises and shortcuts taken by developers during the developmental stage of code writing in an effort to meet budgetary and time constraints. Sometimes it is due to sloppiness, laziness or ignorance. Whatever the case may be, like financial debts, the negative aspects must be dealt with sooner or later. 

The problem with creating a lot of technical debt is that it makes it impossible to adapt it to new platforms or create a solution. Although some technical debt can’t be avoided, by working harder to control it, you can avoid higher development costs and future complications that can even bring a company to a standstill. You also have to keep in mind that using versions or technologies that are not supported anymore can make the solution defenseless. Technical debt allows businesses to create software faster, but they need to be prepared to experience a slowdown in software development in the future.

Identifying Technical Debt

One of the biggest issues concerning technical debt is that it’s not always obvious. Unlike financial debt, which can be seen in an account statement, you should be aware of certain indicators that can help your team recognize technical debt.

  • Technical debt usually manifests itself in statements heard from team members: “It’s easier to copy and paste the code”, “if I mess with the code everything will stop working” and “the only person who knows how to change this code is Bob.” You’ll also find a number of FIXMEs and TODOs in the code.

  • If there is no change with external circumstances or scrum teams, yet you find the velocity is decreasing, you probably have too much technical debt in the software system.

  • A strong indicator of technical debt is when your system is using old libraries which are not being maintained, or there is a newer version that is more productive.

  • You can use tools like SonarJ, Structure 101 or Sonar to automatically measure some technical debt. Although this is not the only type of solution, it is very helpful. Developers can use Sonar to help them follow critical code metrics, like method size and appropriate class. You can use Structure 101 to discover structural issues such as cyclic dependencies. For example, if you have two elements that depend on each other, then a change in one element can affect the other. Not only do they need to be changed together, but they should be developed separately to get the best results.

  • There are many cases in which technical debt can’t be found in the code because the developer used the wrong kind of technology, used clumsy solutions, created the wrong design for a solution, or are hacks that tools can’t easily find. In such cases, other indicators are used to measure technical debt, including a permanent decrease in velocity, bugs rising rapidly at every release or - if at the end of a release - the team is under severe stress.

  • Another major indicator is when you experience constant problems in production, and they become so considerable that you can no longer rely on the operation.

Although there are several ways to measure these indicators, which are not always found in the code, it is best to solve these problems as soon as possible to prevent higher costs in the future.  

Managing Technical Debt

Ignoring technical debt is not an option. It’s important the team works together, even if you are not a developer, in an effort to find the best option for short-term, mid-term and long-term success. In an effort to cut down on technical debt as much as possible and save your business from future additional costs, we offer some approaches that can be very useful.

Buffer-task - You team can create a buffer-task for every release with a fraction of the time. The time can be recorded for that task for possible scheduled refactorings, and can be used when and if problems appear later on.

Cleanup-release - With this approach, teams create a technical release in which they can go back and improve the codebase periodically. However, this only works if there is already a list with the necessary refactorings. Since this approach can delay new features, you will need support from the business side as well. A cleanup release is ideal when extensive changes need to be made in the codebase and architecture.

Technical Backlog - This is considered the best approach in order to determine technical work packages. You can create tasks in a requirements management tool or task tracker and give a quick description of what changes need to be made, why it’s important and where in the code it needs to be changed. You also need to come up with an estimation of how long it will take to solve the problem. This approach is very popular because it comes with many advantages, including:

  • The technical debt is available for everyone to see and a decision can be made as a team about the best time a refactoring task can be done, and how it will affect other code changes.

  • You can easily track the cost for each task.

  • There is mix up between feature tasks and technical tasks.

There are also some disadvantages:

  • You allow the customer to make decisions about prioritizing tasks and the backlog, but they can only help up to a point. They need detailed knowledge about the software in order to determine the importance of a technical task.

  • Because some customers don’t understand why certain features can benefit the business, they can mistrust the need for a technical task.

How To Avoid Technical Debt

As mentioned earlier in the article, some technical debt cannot be avoided, especially for startups with limited money. In order to save time and money in the future, it is important you understand how important the development process is to the success of your business. Although your instinct may be to put some money aside so your business has a little cushion until it gets off the ground, spending a little more on developing at the start can prevent a lot of headaches. Here are a few other tips that can help you avoid technical debt.

  • Build a professional team that you know will take the time and make the effort to help you achieve your business goals. Choose technology that will help your business evolve.

  • Always properly document your code so you can cut down support and maintenance costs while securing its transferability.

  • Use automated testing to find losses in the accuracy and integrity of the software features.

  • In order to keep track of your software system’s health, you’ll want to implement periodic bug management and fix issues that will help your business grow and evolve.

Although technical debt is a way to save money and get your software project finished quicker, it always leads to higher costs in the future. It’s important you take your time and find the right team that shares your enthusiasm to create software with as little technical debt as possible. Ignoring technical debt can be disastrous and can cause businesses to come to a standstill if their software isn’t working properly.

If you have experience managing technical debt successfully and want to help other freelancers improve their development skills, please share your tips and experiences below.

 

Nächster Beitrag

Have You Seen Stack Overflow's Salary Calculator?