Self-Admitted Technical Debt in the Embedded Systems Industry: An Exploratory Case Study

TL;DR

This study explores how embedded systems developers perceive and manage Self-Admitted Technical Debt (SATD), revealing characteristics, attitudes, triggers, and practices through interviews and data analysis in an industrial context.

Contribution

It provides the first in-depth industrial perspective on SATD, including developer attitudes, management practices, and challenges, which were previously underexplored compared to open source projects.

Findings

Identified core characteristics of SATD in industry

Revealed developers' attitudes and statistics towards SATD

Outlined practices and challenges in managing SATD

Abstract

Technical debt denotes shortcuts taken during software development, mostly for the sake of expedience. When such shortcuts are admitted explicitly by developers (e.g., writing a TODO/Fixme comment), they are termed as Self-Admitted Technical Debt or SATD. There has been a fair amount of work studying SATD management in Open Source projects, but SATD in industry is relatively unexplored. At the same time, there is no work focusing on developers' perspectives towards SATD and its management. To address this, we conducted an exploratory case study in cooperation with an industrial partner to study how they think of SATD and how they manage it. Specifically, we collected data by identifying and characterizing SATD in different sources (issues, source code comments, and commits) and carried out a series of interviews with 12 software practitioners. The results show: 1) the core characteristics of SATD in industrial projects; 2) developers' attitudes towards identified SATD and statistics; 3) triggers for practitioners to introduce and repay SATD; 4) relations between SATD in different sources; 5) practices used to manage SATD; 6) challenges and tooling ideas for SATD management.