CLOSED Call for Papers: Special Issue on Technical Debt: 10 Years of Research and Practice
Share this on:
Submissions Due: 18 April 2021
Submissions due: 18 April 2021
Publication: November/December 2021
Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt (TD) metaphor has gained significant traction as a way to understand and communicate such issues. The idea is that developers sometimes implement sub-optimal solutions with respect to one dimension (e.g., modularity) to meet an urgent demand in some other dimensions (e.g., a delivery deadline). Such compromises can be compared to incurring a “debt” on which “interest” (e.g., increased maintenance cost, increased cost for adding new features, or other negative impacts) has to be paid and of which the “principal” should be repaid (e.g., refactoring the code to improve its modularity) at some point for the long-term health of the project. The main goal in managing TD is to enable developers to write high-quality and highly maintainable code accumulating the lowest amount of TD as economically feasible, while continuing to develop in different languages and with different technologies. The main challenge for TD management is to balance refactoring activities (TD removal) and quality assurance versus the development of new product features. Therefore, companies need to understand when TD causes high interest (e.g., increases development cost or hinders evolution) and when it does not.
Starting from the Managing Technical Debt workshop in 2010, practitioners and researchers have been actively working on TD, identifying and discussing TD issues, and sharing emerging practices used in software-development organizations. Thanks to this effort, the community behind TD has been growing within the last 10 years, creating conferences and workshops focused on TD and co-located with the most important venues for software engineering, such as ICSE.
After 10 years of intensive research and practical work, it is time to gather insights on how such effort has influenced the status of practice. For example, how do practitioners identify and calculate TD, how do they identify the main TD factors, and how do they manage and prioritize TD in practice? The accepted papers will report the main advances achieved on TD identification and management during these 10 years, and would highlight the gaps in practice for which solutions are still missing, directing the research activities in the near future.
This theme issue will be the first dedicated to reflecting on the status of the art and practice after 10 years of research on TD. The issue will focus especially on the practical perspectives offered from and in collaboration with industry. We invite papers covering any aspect of TD including, but not limited to:
Frameworks/tools to measure TD
Best practices to manage TD
Industrial experience on managing TD
Economical and business aspects related to TD
Relation between TD and software engineering processes (e.g., the influence of TD on quality, maintenance, testing, or requirements engineering)
Success and failure experiences of TD management
Causes and effects of TD
Manuscripts must not exceed 3,000 words, including figures and tables, which count for 250 words each. Submissions in excess of these limits may be rejected without refereeing. The articles we deem within the theme and scope will be peer reviewed and are subject to editing for magazine style, clarity, organization, and space. Be sure to include the name of the theme you’re submitting for. Articles should have a practical orientation and be written in a style accessible to practitioners. Overly complex, purely research-oriented or theoretical treatments aren’t appropriate. Articles should be novel. IEEE Software doesn’t republish material published previously in other venues, including other periodicals and formal conference or workshop proceedings, whether previous publication was in print or electronic form.