The Relationship Between Incident Management and Technical Debt

by

A relationship that is often overlooked in software development and maintenance is the one between incidents and technical debt. However, upon closer inspection it is a quite obvious one. New or recently revised code is often the cause of most software errors, but those problems that are caused by changes made to code often lead back to a patch of code that is burdened with technical debt. This shouldn't be surprising since technical debt results in code that has baked-in problems (whether they be in design, execution, or integration with the rest of the program) so any interaction with it later on will bring those problems to the surface.

Developers are likely to incur technical debt when speed of work takes precedence over quality of work; so code is added onto a system that although has no bugs does not meet contemporary coding or design standards. This leads to code that does not stand the test of time and when changed or added onto causes more problems than it should. For example, added traffic or structural changes can expose the underlying issues in tech debt ridden code.

But where does incident management tie into this?

Not every incident requires there be an analysis or revision of source code after the fact, but many do. When code is being revised is the most common sense moment in which to eliminate any technical debt that is present. And even if the incident response doesn't require any changes to code it can have revealed some previously unknown technical debt that can logged and dealt with by refactoring. Incident revision can also become a warning system for possible design and code issues.

If technical debt is a significant issue in your current system than it is best to adopt a policy and framework for dealing with it.

This policy and framework should include:

  • Mapping out known areas of technical debt in source code
  • Procedures for logging incidents involving any new or known debt
    • Logs should include: time and date of discovery, basic description of the debt response, and follow up
  • Guidelines covering when to go in and refactor the debt as part of the incident response or when to report the debt and schedule it for a future time
  • A set of formal standards that specifically reference technical debt
    • This involves knowing how to recognize tech debt and also which standards to apply when you refactor it

The great part of recognizing the tie between incident management and technical debt is that you can also tie together your incident management system to your technical debt framework (like your system's API). Doing this makes it possible to pay back technical debt bit by bit as part of incident management and response, and also provides an automated way of assuring that technical debt is not ignored.

To read the original post, visit 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

|