An Empirical Study of Design Degradation: How Software Projects Get Worse over Time

Abstract

Context: Software decay is a key concern for large, long-lived software projects. Systems degrade over time as design and implementation compromises and exceptions pile up.Goal: Quantify design decay and understand how software projects deal with this issue. Method: We conducted an empirical study on the presence and evolution of code smells, used as an indicator of design degradation in 220 open source projects.Results: The best approach to maintain the quality of a project is to spend time reducing both software defects (bugs) and design issues (refactoring). We found that design issues are frequently ignored in favor of fixing defects. We also found that design issues have a higher chance of being fixed in the early stages of a project, and that efforts to correct these stall as projects mature and the code base grows, leading to a build-up of problems.Conclusions: From studying a large set of open source projects, our research suggests that while core contributors tend to fix design issues more often than non-core contributors, there is no difference once the relative quantity of commits is accounted for. We also show that design issues tend to build up over time.

On the relationship between design discussions and design quality: a case study of Apache projects

“…Different ways of measuring design quality have been investigated. Many researchers [12,13,24,25,44,46,47,52,56,69,70] have used code smells [32] to quantify design quality. Code smells are symptoms of poor design and implementation choices [32].…”

“…Researchers have also investigated how design quality evolves over time and found that small changes accumulating over time cause the design drift [74]. Ahmed et al [13] found that software design quality, measured using code smell, gets worse over time. Researchers have also studied the relationship between project activities and design quality [52,59] and found that code reviews have a significant influence on reducing code smells.…”

“…To investigate how design discussions correlate with design quality over time, we could use different ways of partitioning time. Some researchers [36,37] have used releases as the unit of time; others have used individual commits, or discrete-time units (years, months, weeks, days) [13,48]. Individual commits are the only "level" measure but would be too fine-grained for our purpose.…”

“…For example, it could mean poor feature selection, terrible UX design, or bad architecture design. While trying to identify a suitable metric for measuring design quality, researchers have investigated different metrics such as Coupling Between Object (CBO), COupling Factor (COF), Weighted Method per Class (WMC), and code smells [13,20,24,44,47,56]. We opted to use the occurrence of code smell as a proxy for (poor) software design quality since a large number of studies have used and validated code smells for the aforementioned purpose [12,13,24,25,44,46,47,52,52,56,69,70].…”

Investigating factors that affect the human perception on god class detection: an analysis based on a family of four controlled experiments

“…Recently, some empirical studies have been carried out to better understand this scenario (Yamashita and Moonen 2013;Palomba et al 2014;LinaresVásquez et al 2014;Ahmed et al 2015;Fu and Shen 2015). Despite this, the area lacks studies addressing the human role on smell detection.…”