Is
software designed to
be simple and elegant more valuable than software that is
complex
and hard to maintain? An Agile process
accepts this as an important fact.
It
may
surprise you to learn software rots. Intellectually we know it really
doesn't, but it might as well. Software rot is caused by improper
design and limited project resources. Complexity creeps in as easy code
changes are made instead of difficult design changes. Code
duplication accumulates rapidly during
maintenance tasks.
After
a while we notice that fixing one bug causes several even more subtle
(and expensive) bugs to occur and the cost of maintenance goes up
significantly. Eventually the cost of maintenance exceeds resources. It
seems as if our code has decayed on its own in spite of our
best
efforts.
Barry Boehm found that as
software proceeded through its life cycle the cost of making a change
became larger. Ratios of 100:1 for making a change after delivery
versus project start are common. But ratios as low as 5:1 can be found.
How flat this curve stays depends on many individual project factors.
This
cost curve is commonly interpreted to mean that you must create
infallible requirements documents followed by
complete, detailed, and
error-free
designs or pay a huge price later. That isn't what it means.
Boehm's findings are not a condemnation
of change but rather a caution
to be prepared when changes
occur. A well run project keeps the cost of
changes lower longer.
There
are three life cycle events that seem