Collective Wisdom from the Experts 69
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.