I have often expressed the view that the people of the organization know where much of their technical debt is, or they can find it fairly quickly. To exploit this resource, what’s needed is a systematic method for gathering what they know to produce a database that can serve as a starting point for further investigation. We might call this part of the debt identification process “crowdsourcing debt identification.”
When an organization first undertakes to manage its technical debt, one of the many initial tasks is identifying its existing technical debt. There are tools for executing some of this task, at least for software assets, and they are useful. But because they’re in an early stage of development, and because many non-software assets also carry technical debt, human assistance is required. And that’s the place where crowdsourcing can help.
For example, if you ask engineers for examples of technical debt in the assets they work on regularly, they can rattle off a few examples without hesitation. But a few days later, while working on whatever task has focus that day, they’ll realize that they could have mentioned another painful item. And they’ll want to report it. Gathering that kind of information is very helpful to the debt identification effort. That’s crowdsourcing in action.
But investment is required for crowdsourcing to be effective. We must educate the people who will be doing the reporting, and we must give them tools to make reporting quick and easy.
Crowdsourcing debt identification will produce a stream of “incident reports” by Debt Reporters (DRs) that must be interpreted by people we might call Debt Report Administrators (DRAs), who then recast the reports for later investigation by experts in the assets involved. Common difficulties that add to workload of DRAs include:
Inconsistent definitions of technical debt
Lack of uniformity in understanding what technical debt is and isn’t can cause DRs to report as potential debt items some artifacts that aren’t manifestations of technical debt, or worse, they might fail to report items that are.
Only education of the DRs about the organizational definition of technical debt can enhance consistency.
Repeated reporting of previously reported debt items
Unaware that an item has been previously reported, DRs might file reports unnecessarily. Some of these duplications are easily identified, but if the language used in the report is different enough, identifying duplicates can take time.
We can reduce duplication by making available descriptions of previously reported items in multiple forms.
Inconsistent descriptions of debt items
DRA must be able to recognize when two different DRs use different language to describe the same debt item. If they do not, then the debt report database will contain an unrecognized duplication.
The asset expert must then address this situation.
Failure to report known debt items
Some people, pressed by the urgency of their “own work,” might not report debt items they know about, or might hurriedly file low-quality reports. A high incidence of this behavior is an indicator of a deeper organizational issue: namely, that some people do not regard technical debt management as a worthy activity.
Tracking report quality and report frequency is one way to determine how much regard the people of the organization have for the debt management effort.
Report format and content
The act of reporting a potential technical debt item must not be burdensome — it must be easy. A Web-based form is a minimum. Users must be able to prefill some fields common to all their reports, and save the result as a template. Fields they might want to prefill include their personal identity and the asset identity. DRs might need several templates, depending upon the number of assets with which they interact. Switching from one template to another must also be easy.
Several authors have proposed report templates, Below is one due to Foganholi, et al. [Foganholi 2015]. (TD is technical debt)
|ID||TD identification number|
|Date||Date of TD identification|
|Responsible||Person or role who should fix this TD item|
|Type||Design, documentation, defect, testing, or other type of debt|
|Project||Name of project or software application|
|Location||List of files/classes/methods or documents/pages involved|
|Description||Describes the anomaly and possible impacts on future maintenance|
|Estimated principal||How much work is required to pay off this TD item on a three-point scale: High/Medium/Low|
|Estimated interest amount||How much extra work will need to be performed in the future if this TD item is not paid off now on a three-point scale: High/Medium/Low|
|Estimated interest probability||How likely is it that this item, if not paid off, will cause extra work to be necessary in the future on a three-point scale: High/Medium/Low|
|Fixed by||Person or role who really fix this TD item|
|Fixed date||Date of TD conclusion|
|Realized principal||How much work was required to pay off this TD item on a three-point scale: High/Medium/Low|
|Realized interest amount||How much extra work was needed to be performed if this TD item was not paid off at moment of detection, on a three-point scale: High/Medium/Low|
While this template might be useful for tracking the technical debt item, it contains fields that aren’t needed for crowdsourcing debt identification. A simplified template for crowdsourcing debt identification might look like this:
|Identifying Report Title||Your identifier for this report|
|Date||Date of report (prefilled)|
|Type||Drop down menu of debt types, including “other”|
|Project||Name of the project sponsoring the work which led to your observation of the debt item|
|Location of debt item||List of assets involved, including specific location within complex assets|
|Description||Describe the debt item including
- Seek further information from the DR.
- Reject the report as not involving technical debt. (Rejection data is used to assess the effectiveness of the education program)
- Attach the report to a new or existing debt item, incorporating relevant information from the report into the debt item’s data.
What the asset experts produce, which contains information like that suggested by Foganholi, et al. will be the basis of further analysis and eventual retirement of the debt item.
- The reporting responsibility might be seen as an addition burden beyond the current workload.
- In many organizations, reporting on technical debt might be seen as a secondary responsibility.
- Unless technical debt retirements rapidly become common occurrences, reporting might be seen as a waste of effort. The reporting itself must therefore be easy.
These phenomena all exert negative pressure on report quality and tend to suppress report frequency. Ease-of-use can mitigate these effects.
[Foganholi 2015] Lucas Borante Foganholi, Rogério Eduardo Garcia, Danilo Medeiros Eler, Ronaldo Celso Messias Correia, and Celso Olivete Junior. “Supporting technical debt cataloging with TD-Tracker tool,” Advances in Software Engineering 2015 (2015): 4.
Available: here; Retrieved: July 7, 2018
Other posts in this thread
- Managing technical debt
- Leverage points for technical debt management
- Undercounting nonexistent debt items
- Demodularization can help control technical debt
- Legacy debt incurred intentionally
- Metrics for technical debt management: the basics
- Accounting for technical debt
- Three cognitive biases
- The resilience error and technical debt
- Synergy between the reification error and confirmation bias
- Retiring technical debt can be a wicked problem
- Retiring technical debt can be a super wicked problem
- Degrees of wickedness
- Crowdsourcing debt identification