The constantly growing amount of software in use, accompanied by huge amount of technical debt, gradually raises concern in the industry. New technologies and software development processes become yet another degree of freedom boosting the complexity. As the software development and delivery techniques evolve, technical debt perspective should follow. Taking into account all software artefacts enabling value delivery to customers, embracing DevOps paradigm and its holistic focus on software development lifecycle, the strategy presented in this paper enabled stabilization of a large telecommunication software system after a set of consecutive complex merges. The research question of this paper looks for evidence whether prioritization of technical debt mitigation efforts bring a faster return on investment. A 2-year-long case study focused on technical debt prioritization and mitigation that was conducted on this software system resulted in improved quality and stabilization of feature development efforts (cost and time based). Therefore, the tangible gains from applying this approach comprise over 50% decrease in stability issues, improved screening by over 30%, and 6 times better predictability of delivery time (reducing allocation of stabilization effort and time).

This paper proposes a technical debt prioritization technique to be used throughout software development lifecycle. Our method stresses a broader perspective of the product, so the focus is kept on optimizing the software artifacts supporting the complete flow of the value for the customer (including e.g. test environment or deployment pipelines). Many technical debt approaches are focused on static code analysis and misconsider business aspects as a separate activity. On the contrary, our method, based on the New Solution Selling Process, strongly advocates for a business perspective. It facilitates technical debt valuation against a predicted product roadmap by a close alignment with a structured sales process and the advancement of sales opportunities. Taking into account prediction of sales, progress of conversations with potential clients and bids, probability that a given functionality will be prioritized for the development, this approach may serve as a reference point for measuring business value of technical debt continuously. This valuation serves as a relative comparison of technical debt items enabling prioritization of effort to pay off technical debt. The method was evaluated on a release of a wireless telecommunication system. The results confirm that the suggested priorities may address the most profitable product areas from the company's perspective and ultimately optimize the value for customers.

In this survey paper on the recent research, the authors evaluate consistency of the use of technical debt terminology and its convergence with the agreed-upon conceptual model. This consistency is important from the perspective of decision makers, who may delay or even abandon investment in a given area of the product, unless the benefits from repaying a specific technical debt are clear enough. Additionally, the paper discusses a degree in which the metaphorical origins of the technical debt term are still present and influence the research. The analysis is focused on the selected conference papers and offers a view on the inherent dynamics behind shaping the technical debt concept and its conceptual model. Besides, by discussing aspects related to cognitive linguistics, this study provides the means to understand this dynamics and equip the reader with suggestions to decrease ambiguity in the research. The results of the research lead to the following conclusions: 1. Ambiguity stemming from the origin of metaphorical expression of technical debt still exists in the research and there is a need to decrease it by e.g. framing, clarification, and explicit limitation of the research field. 2. Tool designers, such as SonarQube, are not bound by the research results and lead to more confusion in defining technical debt. 3. Risk Management models should be applied to enable technical debt management by decision makers. Thus, Architecture Tradeoff Analysis Method and other Quality Attribute Models may serve as good references to expand the current technical debt model. Even though some ambiguity is still present, the technical debt concept as a software development artifact and agreed-upon conceptual model provide a consistent approach for interpretation and analysis of technical debt phenomenon. Notably, code smells can be mapped to a list of symptoms of technical debt items.