The 60/60 Rule

The 60/60 Rule

David Wood Fredericksburg, Virginia, U.S.

WE oFTEn PRETEnD that software development is the most important part of the software life cycle. 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 life cycle 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 main- tenance, 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 life cycle costs related to maintenance, coupled with 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 envi- ronments. 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 mainte- nance. 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 prompt us to rethink the focus of software develop- ment, 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, enhancement time, or cost at all. To reduce maintenance costs, we have to address the costs associated with understanding code, adjust- ing 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 systems 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 together at the last possible moment and in a flexible manner.