Facts and Fallacies of Software Engineering
I have ambivalent feeling related to this book.
First time I have read I thought that this book is obvious. (At that time I was reading many of the book it is referring to).
The second occasion I have realized that from an objective point of view it is a great book.
Reading the third time (after partially reading "How to measure anything") I had to admit how important the book is. It is full of evidences, statistical facts, studies to prove how valuable each of the statement it has.
Must read!
People
-
The most important factor in software work is the quality of the programmers.
-
The best programmers are up to 28 times better than the worst programmers.
-
Adding people to a late project makes it later.
-
The working environment has a profound impact on productivity and quality.
Tools and Techniques
-
Hype (about tools and technology) is a plague on the house of software.
-
New tools and techniques cause an initial loss of productivity / quality.
-
Software developers talk a lot about tools, but seldom use them.
Estimation
-
One of the two most common causes of runaway projects is poor estimation.
-
Software estimation usually occurs at the wrong time.
-
Software estimation is usually done by the wrong people.
-
Software estimates are rarely corrected as the project proceeds.
-
It is not surprising that software estimates are bad. But we live and die by them anyway!
-
There is a disconnect between software management and their programmers.
-
The answer to a feasibility study is almost always “yes”.
Reuse
-
Reuse-in-the-small is a solved problem.
-
Reuse-in-the-large remains a mostly unsolved problem.
-
Reuse-in-the-large works best in families of related systems.
-
Reusable components are three times as hard to build and should be tried out in three different settings.
-
Modification of reused code is particularly error-prone.
-
Design pattern reuse is one solution to the problems of code reuse.
Complexity
-
For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
-
Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
Requirements
-
One of the two most common causes of runaway projects is unstable requirements.
-
Requirements errors are the most expensive to fix during production.
-
Missing requirements are the hardest requirements errors to correct.
Design
-
Explicit requirements ‘explode’ as implicit requirements for a solution evolve.
-
There is seldom one best design solution to a software problem.
-
Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.
Coding
-
Designer ‘primitives’ rarely match programmer ‘primitives’.
-
COBOL is a very bad language, but all the others are so much worse.
Error removal
-
Error removal is the most time-consuming phase of the lifecycle.
Testing
-
Software is usually tested at best to the 55 to 60 percent coverage level.
-
One hundred percent test coverage is still far from enough.
-
Test tools are essential, but rarely used.
-
Test automation rarely is. Most testing activities cannot be automated.
-
Programmer-created, built-in debug code is an important supplement to testing tools.
Reviews and Inspections
-
Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
-
Rigorous inspections should not replace testing.
-
Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
-
Reviews are both technical and sociological, and both factors must be accommodated.
Maintenance
-
Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
-
Enhancements represent roughly 60 percent of maintenance costs.
-
Maintenance is a solution– not a problem.
-
Understanding the existing product is the most difficult maintenance task.
-
Better methods lead to more maintenance, not less.
Quality
-
Quality is a collection of attributes.
-
Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.
Reliability
-
There are errors that most programmers tend to make.
-
Errors tend to cluster.
-
There is no single best approach to software error removal.
-
Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
Efficiency
-
Efficiency stems more from good design than good coding.
-
High-order language code can be about 90 percent as efficient as comparable assembler code.
-
There are tradeoffs between optimizing for time and optimizing for space.
Research
-
Many researchers advocate rather than investigate.
And the list of fallacies:
Management
-
You can’t manage what you can’t measure.
-
You can manage quality into a software product.
People
-
Programming can and should be egoless.
Tools and Techniques
-
Tools and techniques: one size fits all.
-
Software needs more methodologies.
Estimation
-
To estimate cost and schedule, first estimate lines of code.
Testing
-
Random test input is a good way to optimize testing.
Reviews
-
“Given enough eyeballs, all bugs are shallow”.
Maintenance
-
The way to predict future maintenance costs and to make product replacement decisions is to look at past cost data.
Education
-
You teach people how to program by showing them how to write programs.
Some reviews: