Facts and Fallacies of Software Engineering

Description

• Copyright 2003
• Dimensions: 7-3/8" x 9-1/4"
• Pages: 216
• Edition: 1st

• Book
• ISBN-10: 0-321-11742-5
• ISBN-13: 978-0-321-11742-7
• eBook
• ISBN-10: 0-321-63065-3
• ISBN-13: 978-0-321-63065-0

The practice of building software is a “new kid on the block” technology. Though it may not seem this way for those who have been in the field for most of their careers, in the overall scheme of professions, software builders are relative “newbies.”

In the short history of the software field, a lot of facts have been identified, and a lot of fallacies promulgated. Those facts and fallacies are what this book is about.

There’s a problem with those facts–and, as you might imagine, those fallacies. Many of these fundamentally important facts are learned by a software engineer, but over the short lifespan of the software field, all too many of them have been forgotten. While reading Facts and Fallacies of Software Engineering, you may experience moments of “Oh, yes, I had forgotten that,” alongside some “Is that really true?” thoughts.

The author of this book doesn’t shy away from controversy. In fact, each of the facts and fallacies is accompanied by a discussion of whatever controversy envelops it. You may find yourself agreeing with a lot of the facts and fallacies, yet emotionally disturbed by a few of them! Whether you agree or disagree, you will learn why the author has been called “the premier curmudgeon of software practice.”

These facts and fallacies are fundamental to the software building field–forget or neglect them at your peril!



Extras

Items

Fact 1

Fact 1 PDF



Sample Content

Online Sample Chapters

Facts of Software Engineering Management

Fallacies of Software Engineering Management

Downloadable Sample Chapter

Click below for Sample Chapter(s) related to this title:
Sample Chapter 5

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

Preface

When I first heard that Bob Glass was going to write this book and model it after my 201 Principles of Software Development, I was a bit worried. After all, Bob is one of the best writers in the industry, and he would provide tough competition for my book. And then, when Bob asked me to write his foreword, I became even more worried; after all, how can I endorse a book that seems to compete directly with one of mine? Now that I have read Fifty-Five Facts, I am pleased and honored (and no longer worried!) to have the opportunity to write this foreword.

The software industry is in the same state of affairs that the pharmaceutical industry was in during the late nineteenth century. Sometimes it seems that we have more snake-oil salespeople and doomsayers than sensible folks practicing and preaching in our midst. Every day, we hear from somebody that they have discovered this great new cure for some insurmountable problem. Thus we have oft heard of quick cures for low efficiency, low quality, unhappy customers, poor communication, changing requirements, ineffective testing, poor management, and on and on. There are so many such pundits of the perfunctory that we sometimes wonder if perhaps some portion of the proclaimed panaceas are possibly practical. Who do we ask? Who in this industry can we trust? Where can we get the truth? The answer is Bob Glass.

Bob has had a history of providing us with short treatises on the many software disasters that have occurred over the years. I have been waiting for him to distill the common elements from these disasters so that we can benefit more easily from his many experiences. The 55 facts that Bob Glass discusses in this wonderful book are not just conjectures on his part. They are exactly what I have been waiting for: i.e., the wisdom gained by the author by examining in detail the hundreds of cases he has written about in the past.

The 55 facts that follow are likely to not be popular with all readers. Some are in direct opposition to the so-called “modern” ways of doing things. For those of you who wish to ignore the advice contained within these covers, I can only wish you the safest of journeys, but I fear for your safety. You are treading on well-trod territory, known to be full of mines, and many have destroyed their careers trying to pass. The best advice I can give you is to read any of Bob Glass’ earlier books concerning software disasters. For those of you who wish to follow the advice contained herein, you too are following a well-trod path. However this path is full of successful testimonies. It is a path of awareness and knowledge. Trust Bob Glass because he has been there before. He has had the privilege of analyzing his own successes and failures along with hundreds of others’ successes and failures. Stand on his shoulders, and you will more likely succeed in this industry. Ignore his advice and be prepared for Bob to call you in a few years to ask you about your project—to add it to his next compilation of software disaster stories.

Alan M. Davis, Spring, 2002

0321117425P07302002

Index

Click below to download the Index file related to this title:
Index



Updates

Submit Errata

