No abstract

Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of shortterm 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

Context: The technical debt metaphor describes the effect of immature artifacts on software maintenance that bring a short-term benefit to the project in terms of increased productivity and lower cost, but that may have to be paid off with interest later. Much research has been performed to propose mechanisms to identify debt and decide the most appropriate moment to pay it off. It is important to investigate the current state of the art in order to provide both researchers and practitioners with information that enables further research activities as well as technical debt management in practice. Objective: This paper has the following goals: to characterize the types of technical debt, identify indicators that can be used to find technical debt, identify management strategies, understand the maturity level of each proposal, and identify what visualization techniques have been proposed to support technical debt identification and management activities. Method: A systematic mapping study was performed based on a set of three research questions. In total, 100 studies, dated from 2010 to 2014, were evaluated. Results: We proposed an initial taxonomy of technical debt types, created a list of indicators that have been proposed to identify technical debt, identified the existing management strategies, and analyzed the current state of art on technical debt, identifying topics where new research efforts can be invested. Conclusion: The results of this mapping study can help to identify points that still require further investigation in technical debt research

No abstract

Technical debt is a metaphor for the effects of delayed software development and maintenance tasks. Due to the delay, software may carry immature artifacts in its lifecycle, e.g., immature design, incomplete documentation, etc., which may affect subsequent development and maintenance activities, and so can be seen as a type of debt that the system developers owe the system. Incurring technical debt is common for software projects and can often increase productivity in the short run. However, like paying interest on the debt, such benefit is achieved at the cost of extra work in future. In this sense the technical debt metaphor characterizes the relationship between the short-term benefits of delaying certain software tasks or doing them quickly and less carefully and the long-term cost of those delays or shortcuts. It should be noted that the extra cost may not be realized if the portion of a system containing technical debt will never be touched in the future. Therefore, the problem boils down to managing risk and making informed decisions on which delayed tasks need to be accomplished, and when. Currently, managers and leaders of software maintenance carry out this risk analysis implicitly, if at all. However, on large systems, it is too easy to lose track of delayed tasks or to misunderstand their impact.