The Causes Of Technical Debt Do Not Exist In A Vacuum

by

Time to market pressures are often identified as one of the key causes of technical debt. This results in a tension between releasing a poor quality application early and releasing a high quality one late. The advantages of releasing a product sooner rather than later can be immense and extremely beneficial for a business – and in the rapidly changing tech environment falling behind can be disastrous. However, one of the common misconceptions about technical debt is that it is only relevant at the code-level of software development, when technical debt can be incurred at any point of the software development life-cycle.

There are two categories of technical debt: intentional and unintentional. For either of these two types of technical debt there are usually positive short term consequences (due to early delivery) and negative long term consequences (due to a low quality standard of software). Despite this similarity between unintentional and intentional technical debt the distinction of their causes needs to be made in order to reduce the prevalence of this quality killing phenomena.

Intentional Causes of Technical Debt:

  • Time constraints placed on development
  • Source code complexity
  • Business decisions which lack technical knowledge and make communication difficult

Unintentional Causes of Technical Debt:

  • Lack of coding standards and guides
  • Junior coders with little experience and poor skills
  • Lack of planning for future developments

The long term effects of the above are longer work hours, error and bug prone code, customer dissatisfaction, and increasing source code complexity. There are several processes that can be set into motion in order to keep technical debt at bay, or to address it before the negative consequences of it reach untenable levels.

They include:

  • Refactoring
  • Bug fixing days
  • Code Reviews
  • Clear coding standards and guides
  • Communication between business, management, and developers

While up until this point, the post does a good job of delineating the common causes, effects, and resolutions of technical debt – it is missing a key factor that would lead to the successful management of technical debt in any organization. Many of the causes of technical debt outlined above are a result cultural issues.

Unrealistic time constraints, green developers, little or no coding standards, and poor communication with the management are results of a method of operation for a business. For example, developers with little experience need to trained in order to reach the standard of work that is expected and needed for the business to thrive. Notice that in this instance there are two things needed: a clear set of standards and sufficient time allotted for training. These two items by themselves are causes of technical debt. Therefore, there is a clear connection between one cause of technical debt to another, and often times one is not present on its own. If there are unrealistic deadlines in an organization there are probably also untrained workers, non-existent standards, and a lack of communication with management to solve these other problems.

No cause of technical debt exists in a vacuum – and in order to address it there needs to be a conversation on why it is occurring and an understanding of what needs to be done to deal with it. If time constraints are a serious issue in an organization because management wants quick releases – the cost of these unrealistic time frames needs to be explained. If this exchange does not occur the cycle of poor quality code and technical debt build-up will continue.

To read the full post go here.

Filed in: Technical Debt
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
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|