Technical Debt: What is it and What to do When You Have it?


Technical debt starts off from building fast and making a slew of decisions based on short-term needs that are detrimental to your products long-term stability and maintainability. This can occur from a conscious decision to take short cuts in order to meet some short-term goal or from a lack of inexperience or knowledge of best practices. Technical debt as a term was developed in order to start a discussion on the mode in which investments were being mad on any given software project; whether it be on prioritizing the short-term over the long-term or investing in training on best practices.

Technical debt as a term allows for a conversation to emerge on the investments and priorities within a development team. This is an important conversation to have as technical debt makes productivity slower the more debt you accumulate. A feature that should take a couple of weeks to develop ends of taking double the time because with so much debt your code base is unmaintainable. Your feedback loop will also get slower and affect the agility of your team drastically compared to how it was when you first started building the product.

Your release cycles will be sluggish and large, and the size of changes made in a given release cycle will be so large that stress levels within a team will also be high. Along with this problem each new release will introduce new bugs because your codebase is difficult to maintain and test properly. You will begin to see a downward spiral start to develop with the more debt you take on.

This won't only affect the product's software quality itself, but also the quality of people who will be willing to work on it. Good developers won't want to be part of this tenuous process, where each release only increases the levels of risk and difficulty of the next one.

A good sign that you have a technical debt problem in your software is whether your code smells; in other words, whether your code or system is flagged by those that are working on it, and complaining about it. Below is a non-exhaustive list of symptoms to code smell and technical debt:

  • rampant copy and past code
  • spaghetti code
  • if you change one thing and it unpredictably breaks something else
  • old libraries and deprecated APIs
  • insufficient test coverage, or slow tests

Something like CAST's Application Analytics Dashboard provides analytics on applications and align IT with business and Finance by looking at your applications health and maintenance effort indicators. It also calculates the cost of technical debt, identifies structural issues arising from debt, and helps to prioritize those debt issues causing the most damage.

Being able to have analytics like this puts you in a position to decide how to handle your technical debt. Do you repay it through refactoring? Do you accept your debt? If the cost of investing in debt repayment is greater than the benefit of working on an OK code base than it's not worth your time. But you need to have insight into your code base to be able to make this decision and you also need to have an understanding of how to identify technical debt. That's why understanding what technical debt is and how it affects you is so important.

To read more visit here.

Filed in: Technical Debt
  This report describes the effects of different industrial factors on  structural quality. Structural quality differed across technologies with COBOL  applications generally having the lowest densities of critical weaknesses,  while JAVA-EE had the highest densities. While structural quality differed  slightly across industry segments, there was almost no effect from whether the  application was in- or outsourced, or whether it was produced on- or off-shore.  Large variations in the densities in critical weaknesses across applications  suggested the major factors in structural quality are more related to  conditions specific to each application. CRASH Report 2020: CAST Research on  the Structural Condition of Critical Applications Report
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
Making sense of cloud transitions for financial and telecoms firms Cloud  migration 2.0: shifting priorities for application modernization in 2019  Research Report
Load more reviews
Thank you for the review! Your review must be approved first
New code

You've already submitted a review for this item