EDBT 2026 Demo / reviewers in the wild / expert
Lou Somers
dblp:321/1674
· DBLP profile ↗
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
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Empirical software engineering
developer studies |
0.7 | 1 | 2023 | 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.7 | 1 | 2023 | 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.7 | 1 | 2023 | 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.7 | 1 | 2023 | 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
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2023 | Self-Admitted Technical Debt in the Embedded Systems Industry: An Exploratory Case StudyabstractTechnical 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 |