Managing technical debt in software-reliant systems
By Nanette Brown, Yuanfang Cai, Yuepu Guo, R. Kazman, Miryung Kim, Philippe B Kruchten, Erin Lim, Alan MacCormack, R. Nord, Ipek Ozkaya and 4 more. FoSER '10, 2010
433 citations recorded by the source corpus.
Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt metaphor is gaining significant traction in the agile development community as a way to understand and communicate such issues. The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a "debt": on which "interest" has to be paid and which the "principal" should be repaid at some point for the long-term health of the project. We argue that the software engineering research community has an opportunity to study and improve this concept. We can offer software engineers a foundation for managing such trade-offs based on models of their economic impacts. Therefore, we propose managing technical debt as a part of the future research agenda for the software engineering field.
Subfields: Artificial Intelligence, Computer Science Applications, Information Systems
View Paper: https://www.semanticscholar.org/paper/f754db80f0e465cfcad4077c5703ff1cdfd8e902
How researchers see this paper
The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.
In Information Systems
Citations in the corpus
- Exploration and Explanation in Computational Notebooks (2018, neutral): “Rather than calling for the elimination of technical debt, recent work acknowledges its inevitability and suggests better ways to manage it [1, 3].”
- A systematic mapping study on technical debt and its management (2015, positive): “…and Sterling deem that TD concerns issues found in the code that affect future development (Barton and Sterling, 2010), while many others such as Brown et al. (2010) hold that TD is a broader concept concerning also issues in other phases of the lifecycle, e.g., requirements or architecture,…”
- When and Why Your Code Starts to Smell Bad (and Whether the Smells Go Away) (2017, neutral): “THE technical debt metaphor introduced by Cunningham [22] explains well the trade-offs between delivering the most appropriate but still immature product, in the shortest timepossible [14], [22], [42], [47], [70].”