Abstract
ContextSoftware engineering is a human activity. Despite this, human aspects are under-represented in technical debt research, perhaps because they are challenging to evaluate.ObjectiveThis study’s objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners.MethodForty participants (N = 40) from twelve companies took part in a mixed-methods approach, consisting of a repeated-measures (r = 5) experiment (n = 200), a survey, and semi-structured interviews. From the qualitative data, it is clear that technical debt activates a substantial portion of the emotional spectrum and is psychologically taxing. Further, the practitioners’ reactions to technical debt appear to fall in different levels of maturity.ResultsThe statistical analysis shows that different design smells (strong indicators of technical debt) negatively or positively impact affective states.ConclusionsWe argue that human aspects in technical debt are important factors to consider, as they may result in, e.g., procrastination, apprehension, and burnout.
Highlights
Software engineering is very much a human activity, but this is sometimes forgotten
We address this gap by employing a mixed-methods approach and following guidelines for psychoempirical software engineering research (“research in software engineering with proper theory and measurement from psychology” (Graziotin et al 2015c))
The research objective of this study is to investigate the relationship between Technical Debt (TD) and affective state from the point of view of software practitioners
Summary
Software engineering is very much a human activity, but this is sometimes forgotten. Empir Software Eng (2021) 26: 105 researchers sometimes neglect to factor in human aspects (Lenberg et al 2015). Technical Debt (TD) is a financial metaphor (Cunningham 1992), typically used within software engineering to explain long-term costs of short-term benefits (Ampatzoglou et al 2015). It is a communicative aid for bridging the knowledge gap between software practitioners and business decision makers. If the metaphor was to miscount (or not account for) pivotal cost-benefit factors, the effect could be detrimental to software companies
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
