Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data.

Lou Somers

dblp:321/1674 · DBLP profile ↗
← Back
1ranked-venue papers
0as first author
1since 2021 · last 2023
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 1 · 1 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Software engineering, system software, and programming languages
1 paper
Software maintenance and evolution · 50% Empirical software engineering · 50%

Topics — the 4 heaviest of 4, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Empirical software engineering
developer studies
0.712023
Self-Admitted Technical Debt in the Embedded Systems Industry: An Exploratory Case Study · IEEE Trans. Software Eng. 2023
Empirical software engineering › software engineering research methodology
industrial case study
0.712023
Self-Admitted Technical Debt in the Embedded Systems Industry: An Exploratory Case Study · IEEE Trans. Software Eng. 2023
Software maintenance and evolution › technical debt
self-admitted technical debt
0.712023
Self-Admitted Technical Debt in the Embedded Systems Industry: An Exploratory Case Study · IEEE Trans. Software Eng. 2023
Software maintenance and evolution
technical debt
0.712023
Self-Admitted Technical Debt in the Embedded Systems Industry: An Exploratory Case Study · IEEE Trans. Software Eng. 2023

Methods — techniques the papers use, named apart from their topics

issue and commit analysis · 0.7interviews · 0.7case study · 0.7
YearPublicationVenuePosition
2023 Self-Admitted Technical Debt in the Embedded Systems Industry: An Exploratory Case Study
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 asSelf-Admitted Technical DebtorSATD. 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.
Mohamed Soliman 0001, Paris Avgeriou, Lou Somers
IEEE Trans. Software Eng.4