ATDM 1.0 FTF Avatar
  1. OMG Issue

ATDM — Lack of illustration of usage of Contextual Technical Debt Measure

  • Key: ATDM-2
  • Status: closed  
  • Source: CAST Software ( Mr. Philippe-Emmanuel Douziech)
  • Summary:

    Illustrate how to make best use of TD measures: vis-à-vis actual organization's objectives as opposed to vis-à-vis ideal no defect situation.
    Expected benefits: more palatable values for non-technical audiences.

    Proposed content
    <<<
    8.5 Technical Debt value communication
    The following scenarios illustrate ways in which the Automated Technical Debt Measure (ATDM) and the Contextual Technical Debt Measure (CTDM) can be used to help communicate about Technical Debt with non-technical audiences, facilitate acceptance, and reap the benefits of the Technical Debt metaphor.

    8.5.1 Problem statement
    ATDM and CTDM are estimating the effort to remove all occurrences of the selected patterns (from ASCSM, ASCRM, ASCPEM, ASCMM specifications, or from a user-defined list).
    First, this is equivalent to a strategy of zero tolerance to defects which may be too stringent (and very likely unnecessary) to implement to all applications, as well as too expensive due to the sheer number of occurrences to remove. This leads to remediation effort values so large they are difficult to accept (even if justifiable), ultimately creating a push back against the whole measurement program.
    Second, there is conceptual debate about the content of Technical Debt. Some says Technical Debt should only account for items that organizations have the intention to remove at some point in time. In other words, if organizations do not plan to completely remove all occurrences of each pattern, they are not to be considered in the Technical Debt measurement.
    Third, some organizations manage quality objectives, such as internal or external Service Level Agreements. That is, they define some requirements on the number of issues that are considered acceptable. In this context, when quality objectives are set with a certain tolerance value, it means that only the occurrences whose removal is needed to reach the target level of tolerance will be effectively removed; the remaining occurrences will remain for lack of incentive to do so. In these frequent situations, the Technical Debt values that are meaningful for the management are the estimations of the effort and cost to reach target values (as opposed to the estimation of the effort and cost to get the total absence of occurrences).

    8.5.2 Recommended approach
    8.5.2.1 When quality objectives are set
    CISQ recommends the computation of the amount of Automated Technical Debt Measure that is required to reach quality objectives that are set for each application.
    As the scope of the measure is adjusted with contextual information, this computation should be exposed as a Contextual Technical Debt Measure to avoid confusion.
    The immediate benefits of such approach are:
    a more relevant value,
    because it would be aligned with organization’s existing management practices, as opposed to a value relative to an hypothetical “zero tolerance” situation;
    a more acceptable value,
    because it would be smaller, having filtered out effort and cost amounts that are not ultimately applicable

    8.5.2.1 When quality objectives are not set
    In case there are no quality objectives set, CISQ recommends the computation of the amount of Automated Technical Debt Measure required to reach arbitrary yet meaningful quality levels (such as the sigma levels).
    The immediate benefits are:
    a perspective on quality levels,
    especially as there are no objectives set, to educate and help justify quality improvement initiatives (e.g., showing that there is an effort to plan to reach a sigma 3 level can resonate with non-technical management audience familiar with these concepts)
    a more acceptable value,
    because it would be smaller, having considered the removal of some occurrences only, (removing all occurrences would be completely unrealistic when dealing with an application for which there are no objectives set).

    8.5.3 Limitations
    Benchmarking
    The adjustments regarding the tolerance are incorporated at the expense of benchmarking, which cannot be accomplished with CTDM except among applications where the CTDM adjustments are identical or acceptably different.
    “Acceptably different” means there are differences in the adjustment criteria but that the organization is accepting and adhering to these differences and their impact on the way to interpret the results.
    As an example, if two applications are assigned different tolerance levels, the organization must use the CTDM measures knowingly: the measured values shall not be used to compare the Technical Debt for these two applications but they shall be used to compare the distance to their respective quality objectives, using a Technical Debt metaphor.

    Value range
    As soon as the tolerance level is not zero, this means that some occurrences will have to be removed and some occurrences will be allowed to remain.
    Each of the candidate occurrence for any given pattern leads to the same unadjusted remediation effort. However, as soon as the adjustment factors kick in, the adjusted remediation effort will very likely differ.
    Therefore, the effort required to remove enough occurrences to reach the quality objective for this pattern becomes a value range, with a minimum value obtained by targeting the occurrences with the smaller adjusted remediation effort values, and with a maximum value obtained by targeting the occurrences with the largest adjusted remediation effort values. Obviously, to keep using a single value, the median or the mean value can be used.
    >>>

  • Reported: ATDM 1.0b1 — Thu, 24 Aug 2017 06:12 GMT
  • Disposition: Resolved — ATDM 1.0
  • Disposition Summary:

    Old 8.5 should be improved to explain use of the TD measure

    Improve 8.5 with more explanatory material.

  • Updated: Tue, 19 Dec 2017 23:02 GMT