Technical Debt: 3 Biggest Organizational Mistakes


Technical debt is a huge problem for many organizations today and if it’s not being addressed, it’s growing. Growing technical debt takes away from funds for innovation, and instead uses it toward maintenance. A recent Compuware article explains that the way in which IT organizations accrue technical debt is similar to how people accrue financial debt. Software development author and speaker Martin Fowler says technical debt “incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.”

While there are many contributors of Technical Debt, here’s some of the biggest mistakes that organizations are making today:

Technical debt can come from many places over an extensive amount of time. As teams move from waterfall to agile they often pick up old code, which comes with a price. Agile is made for speed, and with speed, the debt can occur quickly too. The key is to have a good test automation environment.

Additionally, technical debt can happen with there’s a lack of documentation. When moving over from waterfall, start from scratch and be sure you’re creating your ‘guideline’ to the code.

Technical debt can also be a result of your mainframe team having too much on their plate. Are they taking on too much work?

Define what DONE means to you when reducing your technical debt. Did you:

  1. Reduce Technical Debt through improvements in structural quality?
  2. Improve application performance, robustness, and security?
  3. Manage risk of business interruption due to application malfunction?

So how do you measure how much technical debt you have, and where to start? Organizations like North Carolina Department of Transportation are using software intelligence to get x-ray like vision into their apps. You can watch this webinar recording for insight into how they used analytics to cut costs and accelerate modernization.

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
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
You've already submitted a review for this item