Technical Debt Folklore – “All technical debt is intentional”

By Dr. Nico Zazworka 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.

Posted by Dr. Nico Zazworka

Dr. Nico Zazworka received his MS and PhD from the University of Maryland and where he is a member of the Experimental Software Engineering Group at the Department of Computer Science. His academic and professional research is concerned about the usefulness of tools and methods that help making technical debt visible, measurable, and manageable. He is currently working as software quality manager for Elsevier Information Systems GmbH in Frankfurt, Germany, and has also been working at the Fraunhofer Center for Experimental Software Engineering in College Park, Maryland. You can receive his contact details from www.zazworka.com Further information on ongoing technical debt research studies can be retrieved from www.technicaldebt.umbc.edu.

Add your comment

XHTML : You may use these tags : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

This is a Gravatar-enabled website. To get your own globally-recognized avatar, please register at Gravatar.com




Comments

  1. The discussion of Technical Debt within the community demonstrates just one thing, there are no experts…just people with random opinions.

    Of course Technical Debt stems from ignorance, neglect, and the intentional deferment of effort.
    1. The ignorant do not know known good software engineering practice.
    2. The neglectful may know known good software engineering practice but lack the respect and discipline to apply it rigorously as intended.
    3. Those who intentionally defer work or take expedient shortcuts are arrogant practitioners who believe their superior skills will permit them to dodge the bullet of consequences for their action.

    Technical Debt is the organizational, project, or engineering neglect of known good practice that can result in persistent public, user, customer, staff, reputation, or financial cost. Shortcuts, expedient activities, and poor practice contributing to the initial product launch or initial operational capability are often cited as justifiable excuses in taking on Technical Debt; but in truth most Technical Debt is taken on without this strategic intent, without even knowing it, and without the wherewithal in capability or capacity to do the job right. Sources of Technical Debt span neglect in engineering, management, and process including:

    1. Sources of Technical Debt in engineering involve neglect in application domain understanding, requirements determination, system and software architecture, iterative multi-level design, staged incremental development, software development life cycle, programming language, middleware, operating system, network interface, and software development environment.
    2. Sources of Technical Debt in management involve neglect in requirements management, estimating, planning, measurement, monitoring and controlling, risk management, process management, team innovation management, supply chain management, team building, personnel management, and customer relationship management.
    3. Sources of Technical Debt in process involve insufficient evidence of explicit goals and readiness to perform, insufficient accountability based on work responsibility matrix, insufficient planning of design levels and staged increments, and insufficient planning, management, and control of software product releases.

    When adopted, Technical Debt becomes the hole in your canoe. Each gallon of water bailed incurs additional cost. Each gallon of water not bailed adds to the sluggishness of the operation.

     — Reply
  2. It’s important to keep in mind, however, that technical debt is not only about code and code quality. Code analysis tools will identify a small number of the black elements. Therefore, code analysis tools aren’t sufficient for identifying technical debt: more often than not, technical debt isn’t related to code and its intrinsic qualities but to structural or architectural choices or to technological gaps. No tool will reveal that, two years ago, the team should have used some tool to internationalize and localize the code.

     — Reply
  3. The short answer to this question is: there are automated tools that exist in order for you to visualize your Technical Debt, but they are very new and I think these tools do need to mature in the coming years. That being said, they are a great starting point and should definitely be leveraged. Leveraging automated tools is critical in technical debt management because it is such a pervasive and widespread problem that in a big organization it is far too big to manage manually. So having good application lifecycle management processes that are automated (such as good test coverage, leveraging continuous integration, implementing continuous surveillance for risk factors, establishing KPIs) is essential. In my risk management days, we had a concept called Key Risk Indicators, which are composite metrics which can be monitored continuously through automated mechanisms. There are some great tools out there that can scan a source code repository and find indicators of poor code quality, inadequate code coverage, severe level agreement failures, poor data quality, etc. But in terms of getting a true visualization of Technical Debt in your system, this is something that is still relatively new and is still evolving in my opinion.

     — Reply