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.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.