For financial debts, the interest charges associated with a unit of debt are (usually) the same for every unit of debt incurred under the same loan agreement. But for technical debt, the MICs associated with a given instance of a class of technical debt might differ from the MICs associated with any other instance of the same class of technical debt, even if those instances of technical debt were incurred at the same time as a result of a single decision or sequence of events.
For most financial debts, a single algorithm determines the interest charges for every unit of a particular class of financial debt. Following the technical debt metaphor, people tend to assume that the MICs on every instance of a particular class of technical debt are uniform across the asset base.
But in practice, uniformity assumptions with regard to MICs are generally unwarranted. Given two different manifestations of the same kind of technical debt, the MICs associated with modifying asset components in and around those two instances can differ significantly. For any given instance of a particular class of technical debt, MICs can depend on whether or not engineers must interact with that part of the asset. And when they do interact with a given asset component, MICs can also depend upon the transparency and condition of that asset component.
For example, an instance of technical debt might reside in a portion of the system that relatively few local experts understand. The people who are capable of doing that work might be in high demand, or heavily committed, or expensive. Subsequent scheduling difficulty can lead to delays or service interruptions associated with completing the required work. That can result in lost revenue, which also contributes to MICs. Meanwhile, instances of the same kind of technical debt residing in other parts of the asset might be addressable by less expert staff, who might be in lesser demand, and less well compensated. Service interruptions might be shorter, and lost revenue less. The MICs associated with these two cases can therefore differ significantly.
As a second example, consider documentation deficits. If an engineer needs access to documentation to determine how to proceed with a task, and that documentation doesn’t exist, the engineer must resort to alternatives that might be more time-consuming, such as reading code or specifications, or interviewing colleagues. But for two given instances of the same kind of technical debt, the need to refer to documentation can differ. Documentation might be needed for one instance in one part of the asset, but not for another.
Another form of documentation deficit can be especially costly. If documentation is needed, and it does exist, but it’s outdated or incorrect, engineers who rely on that documentation might make costly, potentially irreversible errors when they undertake maintenance or extension activity. A less-damaging case is one in which testing uncovers the defects they unwittingly introduced due to the defective documentation. But if the defects aren’t caught in testing, and if those defects somehow find their way into production, the revenue or liability impact can be substantial, and it can vary from instance to instance of the technical debt in question. These effects are all forms of MICs.
So MICs can vary almost on an instance-by-instance basis. Or they might be constant across instances. It’s difficult to say. But the easy assumption—that MICs are the same for all instances of a given class of technical debt—the easy assumption is probably incorrect.
Available: here Retrieved: November 29, 2017