A Call for Removing Variability

Abstract

Software variability is largely accepted and explored in software engineering and seems to have become a norm and a must, if only in the context of product lines. Yet, the removal of superfluous or unneeded software artefacts and functionalities is an inevitable trend. It is frequently investigated in relation to software bloat. This paper is essentially a call to the community on software variability to devise methods and tools that will facilitate the removal of unneeded variability from software systems. The advantages are expected to be numerous in terms of functional and non-functional properties, such as maintainability (lower complexity), security (smaller attack surface), reliability, and performance (smaller binaries).

Visualization of object-oriented software in a city metaphor: Comprehending the implemented variability and its technical debt

“…While we could adapt JFreeChart's build configuration to be analyzed by a local SonarQube instance [109], we could not achieve to do so for the other systems. We therefore chose 6 other systems for which the quality metrics are available on SonarCloud 18 , allowing us to reuse these metrics for our study. Five of them (Azureus, GeoTools, JKube, OpenAPI Generator and Spring framework) were chosen as their documentation clearly states they implement variability.…”

“…In this work, we target OO codebases that are not associated in any way with additional information regard-ing variability (e.g., UML-based variability description, source code annotations). As a consequence, managing this variability becomes increasingly difficult throughout the evolution of the system [4,17,18], eventually leading to technical debt [19,20]. The technical debt represents short-term applications of design and implementation constructs that make future modifications more costly or impossible, thus impacting system's maintainability and evolution [20].…”