A Balancing Act: What Software Practitioners Have to Say about Technical Debt

Seeking Technical Debt in Critical Software Development Projects: An Exploratory Field Study

“…Even in critical domains that are considered to be more stable, software requirements might change over the course of a project, especially if these requirements are not clearly defined and specified at the beginning of the project. Such deficiencies in requirements specification might lead to the occurrence of requirements debt [17,21,22].…”

“…Sometimes firms have to make trade-offs between long-term software quality and short-term productivity [15,22,30]. In such situations often quality practices are neglected to deal with the urgent demands imposed by the business environment [13,16].…”

“…For example, according to [16], planned tests are often neglected or postponed due to insufficient amount of time. A group of studies use the metaphor of technical debt [19] to explain such quality compromising trade-offs [15,17,21,22].…”

“…However, in last two decades the metaphor has been used in a variety of ways to explain flaws and imperfections in documentation, design, coding and testing activities [17,[20][21][22]. In this study, following [15,17,22] we use the definition of technical debt as conscious decisions to cut back on software development processes in order to minimize development costs and delivery times.…”

“…In such situations, developers are often forced or motivated to cut back on software development processes or to postpone certain activities [17,18]. The metaphor of technical debt [19] has been increasingly used to point out such quality compromising shortcuts [15,17,[20][21][22].…”