eBook
Related collections and offers
Overview
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!
Product Details
| ISBN-13: | 9780321630094 |
|---|---|
| Publisher: | Pearson Education |
| Publication date: | 10/28/2002 |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 216 |
| Sales rank: | 884,235 |
| File size: | 341 KB |
About the Author
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. Robert is trusted by many as a leading authority on software engineering, especially by those who read his columns in Communications of the ACM and IEEE Software. Robert also publishes a newsletter, The Software Practitioner, and speaks frequently at software engineering events.
Read an Excerpt
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 facts—if remembered—might 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, excessive—or 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, clear—and 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 that they all represent fact, but that doesn’t mean you have to.
A few fallacies? There are some sacred cows in the software field that I just couldn’t resist skewering! I suppose I have to admit that the things I call fallacies are things that others might call facts. But part of your fun in reading this book should be forming your own opinion on the things I call facts—and the things I call fallacies.
How about the age of these facts and fallacies? One reviewer of this book said that parts of it felt dated. Guilty as charged. For facts and fallacies to be forgotten frequently, they must have been around for awhile. There are plenty of golden oldies in this collection. But here I think you will find some facts and fallacies that will surprise you, as well—ideas that are “new” because you’re not familiar with them. The point of these facts and fallacies is not that they are aged. It’s that they are ageless.
In this part of the book, I want to introduce the facts that follow. The fallacies will have their own introduction later in the book. My idea of an introduction is to take one last trip through these 55 frequently forgotten fundamental facts and see how many of them track with all of those F-words. Putting on my objectivity hat, I have to admit that some of these facts aren’t all that forgotten.
- Twelve of the facts are simply little known. They haven’t been forgotten; many people haven’t heard of them. But they are, I would assert, fundamentally important.
- Eleven of them are pretty well accepted, but no one seems to act on them.
- Eight of them are accepted, but we don’t agree on how—or whether—to fix the problems they represent.
- Six of them are probably totally accepted by most people, with no controversy and little forgetting.
- Five of them, many people will flat-out disagree with.
- Five of them are accepted by many people, but a few wildly disagree, making them quite controversial.
That doesn’t add up to 55 because (a) some of the facts could fit into multiple categories, and (b) there were some trace presences of other categories, like “only vendors would disagree with this.” Rather than telling you which facts fit into which of those categories, I think I’ll let you form your own opinion about them.
There’s controversy galore in this book, as you can see. To help deal with that, following each discussion about a fact, I acknowledge the controversies surrounding it. I hope, by doing that, I will cover your viewpoint, whether it matches mine or not, and allow you to see where what you believe fits with what I believe.
Given the amount of controversy I’ve admitted to, it probably would be wise of me to tell you my credentials for selecting these facts and engaging in this controversy. (There’s a humorous bio in the back of the book, so here I’ll make it quick.) I’ve been in the software engineering field for over 45 years, mostly as a technical practitioner and researcher. I’ve written 25 books and more than 75 professional papers on the subject. I have regular columns in three of the leading journals in the field: The Practical Programmer in Communications of the ACM, The Loyal Opposition in IEEE Software, and Through a Glass, Darkly in ACM’s SIGMIS DATABASE. I’m known as a contrarian, and I have a plaque identifying me as the “Premier Curmudgeon of Software Practice” to prove it! You can count on me to question the unquestionable and, as I said earlier, to skewer a few sacred cows.
There’s one additional thing I’d like to say about these facts. I’ve already said that I carefully picked them to make sure they were all fundamental to the field. But for all my questioning about how many of them are really forgotten, nearly all of them represent knowledge that we fail to act on. Managers of practitioners make proclamations showing that they’ve forgotten or never heard of many of them. Software developers work in a world too constrained by their lack of knowledge of them. Researchers advocate things that they would realize are absurd if they were to consider them. I really do believe that there’s a rich learning experience—or a rich remembering experience—for those of you who choose to read on.
Now, before I turn you loose among the facts, I want to set some important expectations. In presenting these facts, in many cases, I am also identifying problems in the field. It is not my intention here to present solutions to those problems. This is a what-is book, not a how-to book. That’s important to me; what I want to achieve here is to bring these facts back into the open, where they can be freely discussed and progress toward acting on them can be made. I think that’s an important enough goal that I don’t want to dilute it by diverting the discussion to solutions. Solutions for the problems represented by these facts are often found in books and papers already published in our field: software engineering textbooks, specialty topic software engineering books, the leading software engineering journals, and software popular-press magazines (although there is profound ignorance mixed in with important information in many of these).
To help with that quest, I present these facts in the following orchestrated structure:
- First, I discuss the fact.
- Then I present the controversies, if any, surrounding the fact.
- And finally, I present the sources of information regarding the fact, a bibliography of background and foreground information. Many of those sources are ancient, by software engineering standards (those are the frequently forgotten facts). Many are as fresh as tomorrow. Some are both.
I’ve aggregated my 55 facts into several categories: those that are
- About management
- About the life cycle
- About quality
- About research
The fallacies are aggregated similarly:
- About management
- About the life cycle
- About education
Ah, enough preparation. I hope you’ll enjoy the facts and fallacies I present here. And, more important, I hope you’ll find them useful.
Robert L. Glass Summer 2002
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
Preface
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 thiswonderful 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