Facts and Fallacies of Software Engineering

by Glass, Robert L.; John Fuller; Paul Becker

• ISBN13: 9780321117427
• ISBN10: 0321117425
• Edition: 1st
• Format: Paperback
• Copyright: 2002-10-28
• Publisher: Addison-Wesley Professional

Summary

Controversial and thought-provoking, many software professionals might disagree with the author's assessments in this handbook, but all will embrace the debate. Glass identifies many of the key problems hampering success in this field. Each fact is supported by insightful discussion and detailed references.

Author Biography

Robert Glass is the founder of Computing Trends. He has written more than a dozen books on software engineering and on the lessons of computing failures

Table of Contents

Acknowledgments.
Foreword.

I. 55 FACTS.

Introduction. @CHAPTER 1. = About Management.

People.

Fact 1. The most important factor in software work is the quality of the programmers.
Fact 2. The best programmers are up to 28 times better than the worst programmers.
Fact 3. Adding people to a late project makes it later.
Fact 4. The working environment has a profound impact on productivity and quality.

Tools and Techniques.

Fact 5. Hype (about tools and techniques) is the plague on the house of software.
Fact 6. New tools/techniques cause an initial loss of productivity/quality.
Fact 7. Software developers talk a lot about tools, but seldom use them.

Estimation.

Fact 8. One of the two most common causes of runaway projects is poor estimation.
Fact 9. Software estimation usually occurs at the wrong time.
Fact 10. Software estimation is usually done by the wrong people.
Fact 11. Software estimates are rarely corrected as the project proceeds.
Fact 12. It is not surprising that software estimates are bad. But we live and die by them anyway!
Fact 13. There is a disconnect between software management and their programmers.
Fact 14. The answer to a feasibility study is almost always “yes” .

Reuse.

Fact 15. Reuse-in-the-small is a well-solved problem.
Fact 16. Reuse-in-the-large remains a mostly unsolved problem.
Fact 17. Reuse-in-the-large works best for families of related systems.
Fact 18. Reusable components are three times as hard to build, and should be tried out in three settings.
Fact 19. Modification of reused code is particularly error-prone.
Fact 20. Design pattern reuse is one solution to the problems of code reuse.

Complexity.

Fact 21. For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
Fact 22. Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.

2. About the Life Cycle.

Requirements.

Fact 23. One of the two most common causes of runaway projects is unstable requirements.
Fact 24. Requirements errors are the most expensive to fix during production.
Fact 25. Missing requirements are the hardest requirements errors to correct.

Design.

Fact 26. Explicit requirements “explode” as implicit (design) requirements for a solution evolve.
Fact 27. There is seldom one best design solution to a software problem.
Fact 28. Design is a complex, iterative process. Initial design solutions are usually wrong, and certainly not optimal.

Coding.

Fact 29. Designer “primitives” (solutions they can readily code) rarely match programmer “primitives” .
Fact 30. COBOL is a very bad language, but all the others (for business applications) are so much worse.

Error-removal.

Fact 31. Error-removal is the most time-consuming phase of the life cycle.

Testing.

Fact 32. Software is usually tested at best at the 55-60 percent (branch) coverage level.
Fact 33. 100 percent coverage is still far from enough.
Fact 34. Test tools are essential, but many are rarely used.
Fact 35. Test automation rarely is. Most testing activities cannot be automated.
Fact 36. Programmer-created, built-in, debug code is an important supplement to testing tools.

Reviews/Inspections.

Fact 37. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
Fact 38. But rigorous inspections should not replace testing.
Fact 39. Post-delivery reviews (some call them “retrospectives” ) are important, and seldom performed.
Fact 40. Reviews are both technical and sociological, and both factors must be accommodated.

Maintenance.

Fact 41. Maintenance typically consumes 40-80 percent of software costs. It is probably the most important life cycle phase of software.
Fact 42. Enhancements represent roughly 60 percent of maintenance costs.
Fact 43. Maintenance is a solution, not a problem.
Fact 44. Understanding the existing product is the most difficult task of maintenance.
Fact 45. Better methods lead to MORE maintenance, not less.

3. About Quality.

Quality.

Fact 46. Quality IS: a collection of attributes.
Fact 47. Quality is NOT: user satisfaction, meeting requirements, achieving cost/schedule, or reliability.

Reliability.

Fact 48. There are errors that most programmers tend to make.
Fact 49. Errors tend to cluster.
Fact 50. There is no single best approach to software error removal.
Fact 51. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.

Efficiency.

Fact 52. Efficiency stems more from good design than good coding.
Fact 53. High-order-language code can be about 90 percent as efficient as comparable assembler code.
Fact 54. There are tradeoffs between size and time optimization.

4. About Research.

Fact 55. Many researchers advocate rather than investigate.

II. 5+5 FALLACIES

5. About Management.

Fallacy 1. You can't manage what you can't measure.
Fallacy 2. You can manage quality into a software product.

People.

Fallacy 3. Programming can and should be egoless.

Tools and Techniques.

Fallacy 4. Tools and techniques: one size fits all.
Fallacy 5. Software needs more methodologies.

Estimation.

Fallacy 6. To estimate cost and schedule, first estimate lines of code.

About the Life Cycle.

Testing.

Fallacy 7. Random test input is a good way to optimize testing.

Reviews.

Fallacy 8. “Given enough eyeballs, all bugs are shallow” .

Maintenance.

Fallacy 9. The way to predict future maintenance cost and to make product replacement decisions is to look at past cost data.

7. About Education.

Fallacy 10. You teach people how to program by showing them how to write programs.

Conclusions.
About the Author.
Index. 0321117425T09232002

Excerpts

This book is a collection of facts and fallacies about the subject of software engineering.Sounds boring, doesn't it? A laundry list of facts and fallacies about building software doesn't sound like the kind of thing you'd like to kick back and spend an hour or two with. But there's something special about these facts and fallacies. They're fundamental. And the truth that underlies them is frequently forgotten. In fact, that's the underlying theme of this book. A lot of what we ought to know about building software we don't, for one reason or another. And some of what we think we know is just plain wrong. Who is the we in that previous paragraph? People who build software, of course. We seem to need to learn the same lessons over and over again, lessons that these factsif rememberedmight help us avoid. But by we I also mean people who do research about software. Some researchers get mired so deeply in theory that they miss some fundamentally important facts that might turn their theories upside-down. So the audience for this book is anyone who's interested in building software. Professionals, both technologists and their managers. Students. Faculty. Researchers. I think, he said immodestly, that there's something in this book for all of you. Originally, this book had a cumbersome, 13-word title: Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering was, well, excessiveor at least those responsible for marketing this book thought so. So cooler heads prevailed. My publisher and I finally settled on Facts and Fallacies of Software Engineering. Crisp, clearand considerably less colorful! I had tried to shorten the original long title by nicknaming it the F-Book, noting the alliteration of all the letter Fs in the title. But my publisher objected, and I suppose I have to admit he was right. After all, the letter F is probably the only dirty letter in our alphabet (H and D have their advocates, also, but F seems to reach another level of dirtiness). So the F-Book this is not. (The fact that an early computer science book on compiler-writing was called the Dragon Book, for the sole reason that someone had I suppose arbitrarily put the picture of a dragon on its cover, didn't cut any ice in this particular matter.) But in my defense, I would like to say this: Each of those F-words was there for a purpose, to carry its weight in the gathering meaning of the title. The 55, of course, was just a gimmick. I aimed for 55 facts because that would add to the alliteration in the title. (Alan Davis's wonderful book of 201 principles of software engineering was just as arbitrary in its striving for 201, I'll bet.) But the rest of the Fs were carefully chosen. Frequently forgotten? Because most of them are. There's a lot of stuff in here that you will be able to say "oh, yeah, I remember that one" and then muse about why you forgot it over the years. Fundamental? The primary reason for choosing this particular collection of facts is because all of them carry major significance in the software field. We may have forgotten many of them, but that doesn't diminish their importance. In fact, if you're still wondering whether to go on reading this book, the most important reason I can give you for continuing is that I strongly believe that, in this collection of facts, you will find the most fundamentally important knowledge in the software engineering field. Facts? Oddly, this is probably the most controversial of the words in the title. You may not agree with all of the facts I have chosen here. You may even violently disagree with some of them. I personally believe tha