Measure it? Manage it? Ignore it? software practitioners and technical debt

@article{Ernst2015MeasureIM,
  title={Measure it? Manage it? Ignore it? software practitioners and technical debt},
  author={Neil A. Ernst and Stephany Bellomo and Ipek Ozkaya and Robert L. Nord and Ian Gorton},
  journal={Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering},
  year={2015}
}
  • Neil A. Ernst, S. Bellomo, I. Gorton
  • Published 30 August 2015
  • Computer Science
  • Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering
The technical debt metaphor is widely used to encapsulate numerous software quality problems. The metaphor is attractive to practitioners as it communicates to both technical and nontechnical audiences that if quality problems are not addressed, things may get worse. However, it is unclear whether there are practices that move this metaphor beyond a mere communication mechanism. Existing studies of technical debt have largely focused on code metrics and small surveys of developers. In this… 

Figures and Tables from this paper

How do software architects perceive technical debt in Colombian industry? An analysis of technical debt causes
TLDR
Results showed that inappropriate planning is the most cited technical debt cause by software architects, however, results differ when comparison against engineers and manager are performed.
Hearing the Voice of Software Practitioners on Causes, Effects, and Practices to Deal with Documentation Debt
TLDR
It is found that documentation debt is strongly related to requirements issues, and a theoretical framework is proposed, which provides a comprehensive depiction of the documentation debt phenomenon.
How junior developers deal with their technical debt?
TLDR
This empirical study observed and surveyed Scrum development teams composed of experienced students in order to understand their quality-related processes on a year-long academic project and proposes a series of recommendations on how to train junior developers to understand and manage technical debt.
Do practitioners intentionally self-fix Technical Debt and why?
TLDR
An online survey on 17 well-known Java and Python open-source software communities finds that a majority of practitioners address their own debt consciously and often and that decisions to fix TD are not superficial but consider balancing costs and benefits, among other factors.
What are the practices used by software practitioners on technical debt payment: results from an international family of surveys
TLDR
It is identified that refactoring was the main practice related to TD payment, along with improving testing and improve design, and an important similarity of TD payment practices between code debt and design debt is discovered.
Familiarity, Causes and Reactions of Software Practitioners to the Presence of Technical Debt: A Replicated Study in the Chilean Software Industry
TLDR
A TD survey indicated that the concept of TD is well understood by software practitioners and that most efforts need to be invested by researchers on offering strategies and tools to support TD management.
Understanding Technical Debt at the Code Level from the Perspective of Software Developers
TLDR
This paper presents the results of a survey involving 74 participants that work in the Brazilian software industry, in order to understand why technical debt is introduced, eliminated and how it is managed in practice, with a focus on the code level.
Technical Debt and Maintainability: How do tools measure it?
The technical state of software, i.e., its technical debt (td) and maintainability are of increasing interest as ever more software is developed and deployed. Since td and maintainability are neither
Impact of Architectural Technical Debt on Daily Software Development Work — A Survey of Software Practitioners
TLDR
It is shown that practitioners experience that the Architectural type of Technical Debt has the highest negative impact on daily software development work, and evidence is provided that does not support the commonly held belief that Architectural Technical Debt increases with the age of the software.
...
1
2
3
4
5
...

References

SHOWING 1-10 OF 41 REFERENCES
Managing technical debt: An industrial case study
TLDR
A study conducted with an industrial partner during their implementation of Agile development practices for a large software development division within the company found that developers considered their own taxonomy of technical debt based on the type of work they were assigned and their personal understanding of the term.
The Correspondence Between Software Quality Models and Technical Debt Estimation Approaches
TLDR
A case study across 10 releases of 10 open source systems in order to evaluate three proposed methods of technical debt principal estimation found that only one estimation technique had a strong correlation to the quality attributes reusability and understand ability.
Managing technical debt in practice: An industrial report
TLDR
This work analyses an industrial project, from the perspective of its decisions and related events, so that it can better characterize the existence of TD and show the evolution of its parameters.
Tracking technical debt — An exploratory case study
TLDR
How and to what extent technical debt affects software projects is explored by tracking a single delayed maintenance task in a real software project throughout its lifecycle and how explicit technical debt management might have changed project outcomes is simulated.
A Balancing Act: What Software Practitioners Have to Say about Technical Debt
An interview study involving 35 practitioners from a variety of domains aimed to characterize technical debt at the ground level to find out how software practitioners perceive it. The study also
An exploration of technical debt
Technical debt: towards a crisper definition report on the 4th international workshop on managing technical debt
TLDR
The current confusion in industry on the definition of technical debt is highlighted, their contributions that have led to a deeper understanding of this concept and the limits of the metaphor, the criteria to discriminate what is technical debt and not, and areas of further investigation are highlighted.
Assessing technical debt by identifying design flaws in software systems
TLDR
A novel framework for assessing technical debt using a technique for detecting design flaws, i.e., specific violations of well-established design principles and rules is proposed, built on top of a set of metrics-based detection rules for well-known design flaws.
A field study of refactoring challenges and benefits
TLDR
A field study of refactoring benefits and challenges at Microsoft through three complementary study methods: a survey, semi-structured interviews with professional software engineers, and quantitative analysis of version history data finds that the refactored definition in practice is not confined to a rigorous definition of semantics-preserving code transformations.
In Search of a Metric for Managing Architectural Technical Debt
TLDR
This paper describes taking an architecture-focused and measurement-based approach to develop a metric that assists in strategically managing technical debt that can be used to optimize the cost of development over time while continuing to deliver value to the customer.
...
1
2
3
4
5
...