What is technical debt

Technical dept introduction

Imagine if you’re building a house, but to speed things up, you decide to skip a few steps in laying the foundation. The house still gets built and it works for a while, but over time, the problems start showing up. You’ll eventually need to invest time and resources to fix these issues, or else risk the house falling apart. That’s pretty much what technical debt is in the world of software development. It’s the price you pay in the future for shortcuts or quick fixes you take today.

It is necessary to understand the term “Technical debt” as a significant term for prioritising work. Technical debt can be created during the design, development or testing phase. Technical debt can also be created if we let some application, platform, or methodology become obsolete. Technical debt has to be accordingly prioritised and put under risk assessment. The Product Owner is accountable for prioritization of work and together with a team does plan on how to decrease debt value. A team and Chapter Lead are responsible for the explanation of technical debt value. In case of long-term ignoring technical debt by the team, a responsible IT manager can escalate the debt cost. Because the word “Technical debt” can be understood differently by different people, this chapter describes the term and its link to prioritization.

Technical debt is the monetization of a future-unfit way of doing Software Engineering, that will inevitably lead to inherited costs in the future, either for the debt creator, or other teams. This cost represents the debt value. It may result from a choice to deliver something faster or recklessly (without the necessary know-how) over making it the right way. Besides that, it emerges in a process known as “software rot” as the various 3rd party platforms and libraries get obsolete and/or upgraded.

Paying intereston a “technical debt” is like continuously paying for a mistake without actually fixing the root cause of the problem.

Paying off“technical debt” means investing time and resources to improve our system or application, so we can finally solve the problem that’s been costing us extra.

How do I know my app suffers (or may suffer) from technical debt?

• Technical debt generates costs over time(also known as paying interest on a technical debt). This could be due to manual maintenance of the app, manual workarounds done by the users, blocked further development of this part of the code etc.
• The Technical debt usually stacks and grows over timedue to more and more workarounds needed as the development continues and/or software degrades. The common mistake here is to neglect the debt early on as it doesn’t generate any significant costs yet

Things that aren’t considered Technical debt:

1. A mistake or error in the application. Fixing these errors is a normal part of making and improving software.
2. When the business changes and the app no longer fits the new needs. This often leads to a formal request to change or update the app.
3. A security issue or a failed security test. These are just other types of mistakes that need fixing.
4. When a part of the app isn’t finished on time. This might be a problem for the project manager or another party, but it doesn’t mean there’s a problem with the app’s technical quality.

Technical debt refers to:

1. An unfixed mistake that, over time, keeps costing us more and more to deal with.
2. A poorly designed part of our system (like the way different parts of our app talk to each other) that makes everything more complicated.
3. When we don’t follow the accepted rules or standards in how we build our software.
4. When we don’t meet all the necessary features or performance requirements that our app is supposed to have.

Types of technical debt

As we saw above, technical debt is a normal result of software development — some of it occurs for good reason. And some types of technical debt are worse than others:

Planned technical debt

This type of technical debt occurs when the organization makes an informed decision to generate some technical debt with a full understanding of the consequences (risks and costs). In the case of planned technical debt, it is critical to be as precise as possible in terms of defining the compromises the organization intends to make. An example could be: “To meet the new release deadline of November, we have decided to forego writing unit tests in the final three weeks of the project. We will write these tests after the release. ”Because these decisions can accumulate quickly over time, it is imperative to maintain a record of them. Doing so will increase the likelihood that technical debt will get addressed and paid down quicker. Otherwise, it will quickly be forgotten, potentially costing the organization big time in the long run.

Unintentional technical debt

This refers to unplanned technical debt that arises due to:

• Poor practices
• Inexperience with new coding techniques
• Rollout issues

For example, a design approach that ends up containing many errors is unintentional technical debt. This type sometimes occurs as the direct result of poor communication within the organization or misalignment between the developers and operations teams.

Software entropy

Also known as software rot, software entropy occurs over time as the software quality slowly deteriorates, leading to problems with usability, errors, or necessary updates. Entropy can occur for several reasons:

• When many developers — many of whom may not understand the intended function and design — make incremental changes that increase complexity, violate Non-Functional Requirements (NFR) or slowly break the code.
• Another aspect can be found in what is perceived to be a decay in the quality of otherwise static software that is the result of the inevitable changes to its environment, which often occur as operating systems and other components are upgraded or retired
• Some parts of technology being used by software became obsolete and created significant risk or debt costs for a single team or whole company.

Planning technical debt into backlogs

The solution to software entropy is refactoring, or patching unsecured or obsolete parts of the software (libraries, frameworks, environments, etc)

Deciding when to tackle technical debt is done alongside setting other goals, like running the business, addressing legal requirements, fixing bugs, and so on. In the flexible and fast-paced world of Agile software development, the team has full ownership of their product. It’s the Product Owner’s job to decide what work is most important.

Sometimes, certain kinds of technical debt might be decided on by people outside of the team. In these cases, the team’s job is to include this work in their plan or “backlog”. If the team continuously ignores the technical debt, then it’s up to the Chapter Leader to manage this backlog of work and decide with the team which tasks are most urgent.

If things get too tricky, they can turn to the IT Manager. The IT Manager is there to help make the tough decisions about what should be done next and can step in if there’s a disagreement about what work is most important.

Technical debt vs Technology development

Technical debt

This group contains hi-prior activities from the technology and business point of view. It is usually centrally managed by Chapter Leads and prioritized with responsible IT Managers and teams. Issues in this category already have or will have a significant impact on the risk or have a very high debt cost.

Technology development

This group contains regular technology development and usually increases development productivity, contains long-term technology product sustainability, or prevents the risk of being in the technical debt category in future.

Identification of technology debt

Identification of technical debt can emerge from three sources. Based on priority and categorization the team is responsible for planning the technical debt into the backlog.

Centrally managed technical debt

Technical debt is centrally managed by IT Management and processed via a standard company planning process. This category usually contains large technical debt that affects the majority of development teams. Technical debt is managed viatechnical backlog.It is usually related to Software Entropy or Unintentional technical debt.

Locally managed technical debt

Technical debt is managed by a team. It is usually related to Planned technical debt. A team is responsible for maintaining its technical debt alongside business priorities.

Identification outside the team

Technical debt that is identified by other teams or tech leaders (architects, Chapter Leaders, IT Managers). It is usually related to Unintentional technical debt, where a team cannot identify technical debt by itself, but someone else does. E.G. a team has designed a bad API or technical solution that seems to be good for the team, but it’s very difficult to build on by other teams. This debt is usually identified in the peer-review process. If the Chapter Leader or IT Manager decide that it belongs to the technical debt category the respective team must accept it as such and deal with it accordingly.

Conclusion

If technical debt is not managed correctly it can destroy a tremendous amount of work of developers and yet it is heavily underestimated by business or incompetent IT managers. The hopes placed in the new system, which is supposed to fundamentally make the operation and operational efficiency of the company cheaper, may turn out to be completely wrong thanks to technical debt.

The biggest risk for projects of any size often comes from the project leaders themselves. These leaders, who are supposed to ensure the project’s success, might sometimes ignore ongoing technical issues, or “technical debt”. Instead of dealing with these issues, they might focus solely on meeting deadlines to get their bonuses. This means they keep asking for more money, just to finish the project on time.

This approach isn’t the best for the business. It’s actually more beneficial if the leaders continually work on both aspects — improving the business features and fixing technical issues at the same time. Addressing technical debt only “after the release” or product launch isn’t as beneficial. It’s the leaders’ responsibility to recognize this and prioritize their project management accordingly, for the greater benefit of the business.