We tend to pretend that software development is the most important part of the software lifecycle. Methodologies abound for development. Books, magazine articles, and blogs focus on development. Development, however, is just not where the money is.
Fully 60% of the lifecycle costs of software systems come from maintenance, with a relatively measly 40% coming from development. That is an average, of course. The actual cost of maintenance may vary from 40% to 80%, depending on the system type and the environment it is deployed into. During maintenance, 60% of the costs on average relate to user-generated enhancements (changing requirements), 23% to migration activities, and 17% to bug fixes.
The 60% of lifecycle costs related to maintenance coupled with the the fact that 60% of maintenance activities relate to enhancements gives us the so-called 60/60 Rule, one of the few proposed “laws” of software maintenance.
Migration activities include moving systems to new hardware or software environments. Migration is, of course, a type of changing requirement. Factoring that into our estimates points out an interesting fact: Over 80% of maintenance activities relate in some way to changing requirements.
Naturally, the ability to change code suggests that one should understand it first. Understanding changes to be made is a major activity during maintenance. Roughly 30% of total maintenance time is spent on understanding an existing software product. The development of understanding applies to all forms of maintenance; changing requirements, migration, and bug fixes.
Understanding is a cost we must pay to maintain code that someone else wrote, or we wrote long enough ago that we no longer have an intimate knowledge of it. During maintenance, understanding code takes the place of new design work found during development for most tasks.
The 60/60 Rule should cause us to rethink the focus of software development, as well as maintenance. The tendency to address development activities may not yield the most impressive gains. Boehm’s early assertion in the early 1980s that proper software engineering discipline can reduce defects by up to 75% may be true (although I seriously doubt it), and became the basis for much work toward development methodologies, but so what?
A good methodology may reduce bugs (17% of the total maintenance effort), but not address migration or enhancement time or cost at all. To reduce maintenance costs we have to address the costs associated with understanding code, adjusting code to new requirements and/or migrating code to new environments.
The 60/60 Rule suggests that we should focus our efforts on creating systems that are maintainable. Our software must be designed to change so they become flexible in the face of new requirements. Designing such systems is one of the next great challenges in software engineering.
We know at least part of the answer. The software components need to become less tightly coupled with one another, much the way the components of the World Wide Web are bound to each other at the last possible moment and in a flexible manner.
By David Wood Fredericksburg, Virginia, USA
[divider scroll_text=”Back To Top”]