RECORD
Antipatterns in Software Classification Taxonomies
Software Engineering · Submitted 19 Apr 2022
abstract compiled · 2026-09-23 · no language-model review
The authors' main claim Our contributions show that existing, and very likely even new, classification attempts are deemed to fail for one or more issues, that we named as the `antipatterns' of software classification tasks.
The compiled record
The paper's own sentences, arranged. Each label is drawn from a closed vocabulary; the number beside it is the probability the classifier gave that label. Numbers in the tables are the authors', checked by code. No sentence in this record was written by a model.
Open the compiled record
The abstract, sentence by sentence
Empirical results in software engineering have long started to show that findings are unlikely to be applicable to all software systems, or any domain: results need to be evaluated in specified contexts, and limited to the type of systems that they were extracted from. This is a known issue, and requires the establishment of a classification of software types. This paper makes two contributions: the first is to evaluate the quality of the current software classifications landscape. The second is to perform a case study showing how to create a classification of software types using a curated set of software systems. Our contributions show that existing, and very likely even new, classification attempts are deemed to fail for one or more issues, that we named as the `antipatterns' of software classification tasks. We collected 7 of these antipatterns that emerge from both our case study, and the existing classifications. These antipatterns represent recurring issues in a classification, so we discuss practical ways to help researchers avoid these pitfalls. It becomes clear that classification attempts must also face the daunting task of formulating a taxonomy of software types, with the objective of establishing a hierarchy of categories in a classification.
background contribution method result interpretation main claim
| # | sentence | role | the authors' own work | states the main conclusion | strength |
|---|---|---|---|---|---|
| s0 | Empirical results in software engineering have long started to show that findings are unlikely to be applicable to all software systems, or any domain: results need to be evaluated in specified contexts, and limited to the type of systems that they were extracted from. | background 1.00 | 0.08 | 0.05 | asserted 0.67 |
| s1 | This is a known issue, and requires the establishment of a classification of software types. | background 0.97 | 0.05 | 0.04 | asserted 1.00 |
| s2 | This paper makes two contributions: the first is to evaluate the quality of the current software classifications landscape. | contribution 1.00 | 0.74 | 0.05 | asserted 0.97 |
| s3 | The second is to perform a case study showing how to create a classification of software types using a curated set of software systems. | contribution 1.00 | 0.92 | 0.04 | asserted 0.95 |
| s4 | Our contributions show that existing, and very likely even new, classification attempts are deemed to fail for one or more issues, that we named as the `antipatterns' of software classification tasks. | result 0.83 | 0.85 | 0.70 | asserted 0.65 |
| s5 | We collected 7 of these antipatterns that emerge from both our case study, and the existing classifications. | result 0.53 | 0.88 | 0.08 | asserted 1.00 |
| s6 | These antipatterns represent recurring issues in a classification, so we discuss practical ways to help researchers avoid these pitfalls. | contribution 0.56 | 0.53 | 0.13 | asserted 0.98 |
| s7 | It becomes clear that classification attempts must also face the daunting task of formulating a taxonomy of software types, with the objective of establishing a hierarchy of categories in a classification. | interpretation 0.85 | 0.22 | 0.20 | asserted 0.97 |
What was examined, and what was not
- arXiv listing abstract v1
- full text
- figures and tables
- references and citing sentences
- relations to other papers
- P abstract
- S sections
- T body sentences
- C citations
- R cross-paper relations
The paper
Original abstract
Empirical results in software engineering have long started to show that findings are unlikely to be applicable to all software systems, or any domain: results need to be evaluated in specified contexts, and limited to the type of systems that they were extracted from. This is a known issue, and requires the establishment of a classification of software types. This paper makes two contributions: the first is to evaluate the quality of the current software classifications landscape. The second is to perform a case study showing how to create a classification of software types using a curated set of software systems. Our contributions show that existing, and very likely even new, classification attempts are deemed to fail for one or more issues, that we named as the `antipatterns' of software classification tasks. We collected 7 of these antipatterns that emerge from both our case study, and the existing classifications. These antipatterns represent recurring issues in a classification, so we discuss practical ways to help researchers avoid these pitfalls. It becomes clear that classification attempts must also face the daunting task of formulating a taxonomy of software types, with the objective of establishing a hierarchy of categories in a classification.
Human review
How the literature uses it
What this paper does with the arXiv papers it cites
Discussion
Know something about this paper? Leave a comment, or highlight any passage above to comment on it.