Software Maintainability
Maintainability is the degree of effectiveness and efficiency with which a product can be modified by intended maintainers [1]. Unlike a binary pass/fail criterion, maintainability is a matter of degree — measured by the unit cost of change. A system where a one-line feature takes one hour is more maintainable than one where the same feature takes one week, even if both eventually produce correct results.
This section covers the arc from why software degrades (Lehman’s Laws, Parnas’s aging), through the ISO 25010 sub-characteristics, to measurement models and industrial case studies that demonstrate how structural interventions restore maintainability.
The Maintenance Iceberg
Most software cost is invisible at release time. The development phase — requirements through initial deployment — accounts for only a fraction of total lifecycle expenditure. The rest is maintenance: corrective, adaptive, perfective, and preventive.
| Statistic | Source |
|---|---|
| ~70% of lifecycle effort goes to maintenance, ~30% to initial development | [2] |
| 70–80% of total lifecycle cost is in operations and support (O&S) | [3] |
| 80–85% of life-cycle cost is committed during requirements and design | [3] |
| ROI of “Design for Maintainability” can reach 1000% vs doing nothing | [3] |
The implication is stark: the cheapest time to invest in maintainability is before code is written, because design decisions lock in 80–85% of future maintenance cost.
ISO 25010: Maintainability
The ISO/IEC 25010 quality model decomposes maintainability into five sub-characteristics [1]:
| Sub-characteristic | Definition |
|---|---|
| Modularity | Degree to which a system is composed of discrete components such that a change to one has minimal impact on others |
| Reusability | Degree to which an asset can be used in more than one system or in building other assets |
| Analyzability | Degree of effectiveness and efficiency with which it is possible to assess the impact of an intended change, diagnose deficiencies, or identify parts to be modified |
| Modifiability | Degree to which a product can be effectively and efficiently modified without introducing defects or degrading quality |
| Testability | Degree of effectiveness and efficiency with which test criteria can be established and tests can be performed to determine whether those criteria have been met |
These five sub-characteristics are not independent. Modularity enables analyzability (isolated modules are easier to reason about), which in turn supports modifiability (well-understood code is safer to change). Testability acts as a feedback mechanism: without it, changes cannot be verified, and modifiability degrades over time [4].
Why Maintainability Degrades
Software does not wear out like hardware, yet it decays. Two complementary theories explain why.
Parnas’s Two Causes of Aging
Parnas identifies two forces that cause software to age [5]:
- Lack of Movement — failure to update the software to keep pace with a changing environment. The software becomes obsolete, even though nothing in it has changed.
- Ignorant Surgery — changes made by people who do not understand the original design. Each such change degrades the structure, making the next change harder and more error-prone.
“Programs, like people, get old. We can’t prevent aging, but we can understand its causes, take steps to limit its effects, temporarily reverse some of the damage it has caused, and prepare for the day when the software is no longer viable.” — D.L. Parnas (1994) [5]
Lehman’s Laws of Software Evolution
Lehman’s empirical Laws I and II formalize the same pressures at the system level [2], [6]:
| Law | Name | Statement |
|---|---|---|
| I | Continuing Change | A system must be continually adapted, or it becomes progressively less satisfactory |
| II | Increasing Complexity | As a system evolves, its complexity increases unless work is done to maintain or reduce it |
Law I corresponds to Parnas’s “Lack of Movement”: stop adapting and the system loses value. Law II corresponds to “Ignorant Surgery”: every modification that does not actively reduce complexity adds to it.
Software Aging: The “One-Two Punch”
Parnas describes the combined effect of both aging forces as a “one-two punch” that accelerates value decline [5]:
The two forces reinforce each other. Lack of Movement creates pressure for urgent changes (“we must catch up”), and urgent changes are precisely the ones most likely to be Ignorant Surgery. The only defense is deliberate investment in design for change: information hiding, separation of concerns, and continuous architectural stewardship [5].
Famous Maintainability Stories
| Case | Year | Problem | Impact | Source |
|---|---|---|---|---|
| Mozilla re-design | 1998–2004 | Monolithic Netscape codebase; propagation cost 17.35% | After open-source restructuring, propagation cost dropped to 2.78% | [7] |
| Microsoft Windows 7 | 2009–2012 | Top 5% most coupled modules caused disproportionate churn | Targeted refactoring achieved 0.85x dependency reduction in critical modules | [8] |
| ABB DID platform | 2014–2016 | 82% code duplication across product variants | Refactoring reduced duplication by 82%; time per new component dropped from 6–8 weeks to 1–2 weeks | [9] |
| Automatic refactoring | 2011–2014 | Manual refactoring too slow for industrial codebases | 4,000 automatic refactorings at 4 companies; 55% improved maintainability, only 10% decreased | [10] |
These cases share a common pattern: maintainability problems are structural, not local. Fixing them requires understanding the dependency architecture — which modules are coupled, where propagation cost is concentrated, and where duplication has accumulated.
Section Overview
| Page | Content |
|---|---|
| Evolution | Lehman’s 8 Laws of Software Evolution, Parnas’s aging theory, complexity growth patterns |
| Measurement | Maintainability Index (MI), SIG model, SQALE method, Cognitive Complexity |
| DSM & Modularity | Design Structure Matrix operations, propagation cost metric, Mozilla vs Linux comparison |
| Case Studies | Microsoft refactoring study, ABB DID platform, Mozilla restructuring — detailed analysis |
References
- ISO/IEC, “ISO/IEC 25010:2011 – Systems and Software Quality Requirements and Evaluation (SQuaRE) – System and Software Quality Models.” International Organization for Standardization, 2011.
- M. M. Lehman, “Programs, Life Cycles, and Laws of Software Evolution,” Proceedings of the IEEE, vol. 68, no. 9, pp. 1060–1076, 1980, doi: 10.1109/PROC.1980.11805.
- L. J. Gullo and J. Dixon, Design for Maintainability. Wiley, 2021.
- J. Visser, S. Rigal, R. van der Leij, P. van Eck, and G. Wijnholds, Building Maintainable Software: Ten Guidelines for Future-Proof Code. O’Reilly Media, 2016.
- D. L. Parnas, “Software Aging,” in Proceedings of the 16th International Conference on Software Engineering (ICSE), IEEE Computer Society Press, 1994, pp. 279–287. doi: 10.1109/ICSE.1994.296790.
- M. M. Lehman, “Laws of Software Evolution Revisited,” in Software Process Technology (EWSPT 1996), in Lecture Notes in Computer Science, vol. 1149. Springer, 1996, pp. 108–124. doi: 10.1007/BFb0017737.
- A. MacCormack, J. Rusnak, and C. Y. Baldwin, “Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code,” Management Science, vol. 52, no. 7, pp. 1015–1030, 2006, doi: 10.1287/mnsc.1060.0552.
- M. Kim, T. Zimmermann, and N. Nagappan, “An Empirical Study of Refactoring Challenges and Benefits at Microsoft,” in IEEE Transactions on Software Engineering, 2014, pp. 633–649. doi: 10.1109/TSE.2014.2318734.
- M. Wahler, U. Drofenik, and W. Snipes, “Improving Code Maintainability: A Case Study at a Large Scale Industrial Project,” in Proceedings of ICSME 2016, IEEE, 2016, pp. 493–497. doi: 10.1109/ICSME.2016.54.
- G. Szőke, G. Antal, C. Nagy, R. Ferenc, and T. Gyimóthy, “Do Automatic Refactorings Improve Maintainability? An Industrial Case Study,” Journal of Systems and Software, 2015, doi: 10.1016/j.jss.2015.03.012.
Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.