C
Casey Hawthorne
Interesting book:
Facts and Fallacies of Software Engineering
by Robert L. Glass
Some of the more interesting and amazing "facts":
Fact 19: Modification of reused code is particularly error-prone. If
more than 20 to 25% of a component is to be revised, it is more
efficient and effective to rewrite it from scratch.
Fact 21: For every 25% increase in problem complexity, there is a 100%
increase in the complexity of the software solution. That's not a
condition to try to change (even though reducing complexity is always
a desirable thing to do); that's just the way it is.
- Why is reuse-in-the-large unsuccessful? (Because complexity
magnifies diversity.)
- Why are there so many different correct approaches to designing the
solution to a problem? (Because the solution space is so complex.)
Fact 26: When moving from requirements to design, there is an
explosion of "derived requirements" (the requirements for a particular
design solution) caused by the complexity of the solution process.
The list of these design requirements is often 50 times longer than
the list of original requirements.
Fact 30: COBOL is a very bad language, but all the others (for
business data processing) are so much worse.
Fact 33: Even if 100% test coverage were possible, that is not
sufficient criterion for testing. Roughly 35% of software defects
emerge from missing logic paths (missing requirements), and another
40% from the execution of a unique combination of logic paths
(Combinatorics). They will not be caught by 100% coverage.
Fact 42: Enhancement is responsible for roughly 60% of software
maintenance costs. Error correction is roughly 17%. Therefore,
software maintenance is largely about adding new capability to old
software, not fixing it.
- The 60/60 rule: 60% of software's dollar is spent on maintenance,
and 60% of that maintenance is enhancement. Enhancing old software
is, therefore, a big deal.
Facts and Fallacies of Software Engineering
by Robert L. Glass
Some of the more interesting and amazing "facts":
Fact 19: Modification of reused code is particularly error-prone. If
more than 20 to 25% of a component is to be revised, it is more
efficient and effective to rewrite it from scratch.
Fact 21: For every 25% increase in problem complexity, there is a 100%
increase in the complexity of the software solution. That's not a
condition to try to change (even though reducing complexity is always
a desirable thing to do); that's just the way it is.
- Why is reuse-in-the-large unsuccessful? (Because complexity
magnifies diversity.)
- Why are there so many different correct approaches to designing the
solution to a problem? (Because the solution space is so complex.)
Fact 26: When moving from requirements to design, there is an
explosion of "derived requirements" (the requirements for a particular
design solution) caused by the complexity of the solution process.
The list of these design requirements is often 50 times longer than
the list of original requirements.
Fact 30: COBOL is a very bad language, but all the others (for
business data processing) are so much worse.
Fact 33: Even if 100% test coverage were possible, that is not
sufficient criterion for testing. Roughly 35% of software defects
emerge from missing logic paths (missing requirements), and another
40% from the execution of a unique combination of logic paths
(Combinatorics). They will not be caught by 100% coverage.
Fact 42: Enhancement is responsible for roughly 60% of software
maintenance costs. Error correction is roughly 17%. Therefore,
software maintenance is largely about adding new capability to old
software, not fixing it.
- The 60/60 rule: 60% of software's dollar is spent on maintenance,
and 60% of that maintenance is enhancement. Enhancing old software
is, therefore, a big deal.