Technical Debt Folklore – “All technical debt is intentional”

By On December 5, 2012 At 1:50 pm

Introduction

Some months ago we presented three webinars to Lockheed Martin, IEEE, and Boeing on current research in automated identification of Technical Debt through code analysis tools. The topics covered a basic introduction of the Technical Debt concepts and terminology, as well as first research results describing how current tools (code smell tools, ASA issue tools, and other tools) can point to areas of debt in a code base. After presenting to more than 600 engineers, we also were interested in common beliefs (i.e. folklore) about technical debt in this community. For this, we invited webinar participants to fill in a short survey. The following presents some of the preliminary highlights of the results.

Survey Goals and Questions

The goal of the survey is to validate a set of statements about Technical Debt. I and my colleagues, Rodrigo Spínola, Forrest Shull, and Carolyn Seaman, searched a number of online websites and blogs, as well as some published papers, for potential folklore statements, and then refined the list into the items in the table below. These statements might have been expressed by individuals or by groups, but were not scientifically based initially. The rationale of our survey method is that, if these statements are confirmed (e.g. commonly agreed or disagreed to) by a large group of practitioners, then they are more likely to be good candidates for future research. On the contrary, mixed answers to a statement can indicate that it is not commonly believed, depends on other factors, or that the statement itself is not yet formulated as concisely as needed. Commonly believed folklore can help researchers to gather ideas for theories, hypotheses, research questions, and follow-up experiments.

The following statements were included in the survey. Participants indicated their level of agreement for each of them using a 5-point Likert scale:“1: strongly disagree”, “2: disagree”, “3: neither agree or disagree”, “4: agree”, or “5: strongly agree”.

  1. Accruing technical debt is unavoidable on any non-trivial software project.
  2. Technical debt usually comes from short-term optimizations of time without regard to the long-term effects of the change.
  3. It is very difficult for software developers to see the true effect of the technical debt they are incurring.
  4. “Working off debt” can be motivational and good for team morale.
  5. The root cause of most technical debt is pressure from the customer.
  6. Unintentional debt is much more problematic than intentional debt.
  7. The individuals choosing to incur technical debt are usually different from those responsible for servicing the debt.
  8. If technical debt is not managed effectively, maintenance costs will increase at a rate that will eventually outrun the value it delivers to customers.
  9. No matter what, the cost of fixing technical debt increases the longer it remains in the system.
  10. Paying off technical debt doesn’t result in anything the customers or users will see.
  11. The biggest problem with technical debt is not its impact on value or earnings, but its impact on predictability.
  12. Technical debt should not be avoided, but managed.
  13. Not all technical debt is bad.
  14. All technical debt is intentional.

Participants and Threats to Validity

We received a rather low number of responses (17 participants), which results in limitations and the need for care when interpreting these numbers. The results are likely to point us in the right direction, but are statistically not significant when evaluated with scientific rigor. Furthermore, this small subset of responses originates from a potentially biased group of participants, i.e. subjects who have had unpleasant experiences with Technical Debt (and so were motivated to attend our webinar).

Results

Results are presented below by rank of agreement and tendency. The former metric orders the statements by their agreement as computed by a statistical measure (standard deviation). This is a rough indicator for the degree to which subjects gave the same answer for a statement, versus statements where answers were mixed, i.e. more spread out across the Likert scale. The latter metric, tendency, is computed as the median of answers on the 5 point Likert scale, indicating if ,on average, subjects agreed or disagreed with the statement.

Agreement
Rank
Statement Tendency
(Median)
1 (high) All technical debt is intentional. 1 – Strongly Disagree
2 If technical debt is not managed effectively, maintenance costs will increase at a rate that will eventually outrun the value it delivers to customers. 5 – Strongly Agree
3 Not all technical debt is bad. 4 – Agree
4 The biggest problem with technical debt is not its impact on value or earnings, but its impact on predictability. 3 – Neither Agree or Disagree
5 Technical debt should not be avoided, but managed. 4 – Agree
6 Technical debt usually comes from short-term optimizations of time without regard to the long-term effects of the change. 4 – Agree
7 The root cause of most technical debt is pressure from the customer. 3 – Neither agree or disagree
7 The individuals choosing to incur technical debt are usually different from those responsible for servicing the debt. 4 – Agree
7 Paying off technical debt doesn’t result in anything the customers or users will see. 2 – Disagree
10 No matter what, the cost of fixing technical debt increases the longer it remains in the system. 3 – Neither agree or disagree
10 It is very difficult for developers to see the true effect of the technical debt they are incurring. 3 – Neither agree or disagree
12 Accruing technical debt is unavoidable on any non-trivial software project. 4 – Agree
13 Unintentional debt is much more problematic than intentional debt. 4 – Agree
14 (low) “Working off debt” can be motivational and good for team morale. 4 – Agree

Interpretation and Conclusions

The first three items in the table offer the strongest evidence of agreement on some Technical Debt folklore. High disagreement with the statement that all Technical Debt is intentional would indicate that many practitioners have been surprised to find Technical Debt that was not incurred intentionally. This supports the ongoing line of research into tools that analyze source code for “hidden” debt. The second item, which was strongly agreed with by our survey participants, indicates that Technical Debt is a very real problem, and can be dangerous if it gets out of hand. This motivates continued research in general, as well as adoption in practice of techniques to manage Technical Debt. In light of the third item, indicating agreement that not all Technical Debt is bad, this also motivates investigation into that “sweet spot” between an acceptable and healthy level of debt, and a level that is approaching dangerous.

7 Steps to Pay Down the Interest on Your IT Technical Debt
Learn how to handle “Technical Debt”

In 2011, there were more IT system failures, outages and data breaches occurred than any previous year since the dawn of the age of technology. And while some of these issues could be traced to intentional and malicious undermining of systems, many, if not most, had some measure of application software failure or weakness at their root.

Your Information will be kept private and secure.