1300 187 187
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!
| Acknowledgments | p. xiii |
| Foreword | p. xv |
| 55 Facts | p. 1 |
| Introduction | p. 3 |
| About Management | p. 9 |
| People | p. 11 |
| The most important factor in software work is the quality of the programmers | p. 11 |
| The best programmers are up to 28 times better than the worst programmers | p. 14 |
| Adding people to a late project makes it later | p. 16 |
| The working environment has a profound impact on productivity and quality | p. 17 |
| Tools and Techniques | p. 19 |
| Hype (about tools and techniques) is the plague on the house of software | p. 19 |
| New tools and techniques cause an initial loss of productivity/quality | p. 23 |
| Software developers talk a lot about tools, but seldom use them | p. 25 |
| Estimation | p. 27 |
| One of the two most common causes of runaway projects is poor estimation | p. 27 |
| Software estimation usually occurs at the wrong time | p. 31 |
| Software estimation is usually done by the wrong people | p. 33 |
| Software estimates are rarely corrected as the project proceeds | p. 35 |
| It is not surprising that software estimates are bad. But we live and die by them anyway! | p. 36 |
| There is a disconnect between software management and their programmers | p. 39 |
| The answer to a feasibility study is almost always "yes." | p. 42 |
| Reuse | p. 43 |
| Reuse-in-the-small is a well-solved problem | p. 43 |
| Reuse-in-the-large remains a mostly unsolved problem | p. 45 |
| Reuse-in-the-large works best in families of related systems | p. 48 |
| Reusable components are three times as hard to build and should be tried out in three settings | p. 49 |
| Modification of reused code is particularly error-prone | p. 51 |
| Design pattern reuse is one solution to the problems of code reuse | p. 55 |
| Complexity | p. 58 |
| For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity | p. 58 |
| Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical | p. 60 |
| About the Life Cycle | p. 65 |
| Requirements | p. 67 |
| One of the two most common causes of runaway projects is unstable requirements | p. 67 |
| Requirements errors are the most expensive to fix during production | p. 71 |
| Missing requirements are the hardest requirements errors to correct | p. 73 |
| Design | p. 76 |
| Explicit requirements "explode" as implicit (design) requirements for a solution evolve | p. 76 |
| There is seldom one best design solution to a software problem | p. 79 |
| Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal | p. 81 |
| Coding | p. 84 |
| Designer "primitives" (solutions programmers can readily code) rarely match programmer "primitives." | p. 84 |
| COBOL is a very bad language, but all the others (for business applications) are so much worse | p. 87 |
| Error Removal | p. 90 |
| Error removal is the most time-consuming phase of the life cycle | p. 90 |
| Testing | p. 91 |
| Software is usually tested at best at the 55 to 60 percent (branch) coverage level | p. 91 |
| One hundred percent coverage is still far from enough | p. 95 |
| Test tools are essential, but many are rarely used | p. 97 |
| Test automation rarely is. Most testing activities cannot be automated | p. 101 |
| Programmer-created, built-in debug code is an important supplement to testing tools | p. 103 |
| Reviews and Inspections | p. 104 |
| Rigorous inspections can remove up to 90 percent of errors before the first test case is run | p. 104 |
| Rigorous inspections should not replace testing | p. 108 |
| Postdelivery reviews (some call them "retrospectives") are important and seldom performed | p. 110 |
| Reviews are both technical and sociological, and both factors must be accommodated | p. 113 |
| Maintenance | p. 115 |
| Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important life cycle phase of software | p. 115 |
| Enhancements represent roughly 60 percent of maintenance costs | p. 117 |
| Maintenance is a solution, not a problem | p. 119 |
| Understanding the existing product is the most difficult task of maintenance | p. 120 |
| Better methods lead to more maintenance, not less | p. 124 |
| About Quality | p. 127 |
| Quality | p. 129 |
| Quality is a collection of attributes | p. 129 |
| Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability | p. 132 |
| Reliability | p. 134 |
| There are errors that most programmers tend to make | p. 134 |
| Errors tend to cluster | p. 135 |
| There is no single best approach to software error removal | p. 137 |
| Residual errors will always persist. The goal should be to minimize or eliminate severe errors | p. 137 |
| Efficiency | p. 139 |
| Efficiency stems more from good design than good coding | p. 139 |
| High-order language code can be about 90 percent as efficient as comparable assembler code | p. 141 |
| There are tradeoffs between size and time optimization | p. 143 |
| About Research | p. 147 |
| Many researchers advocate rather than investigate | p. 148 |
| 5+5 Fallacies | p. 151 |
| Introduction | p. 153 |
| About Management | p. 155 |
| You can't manage what you can't measure | p. 155 |
| You can manage quality into a software product | p. 158 |
| People | p. 160 |
| Programming can and should be egoless | p. 160 |
| Tools and Techniques | p. 161 |
| Tools and techniques: one size fits all | p. 161 |
| Software needs more methodologies | p. 164 |
| Estimation | p. 167 |
| To estimate cost and schedule, first estimate lines of code | p. 167 |
| About the Life Cycle | p. 171 |
| Testing | p. 171 |
| Random test input is a good way to optimize testing | p. 171 |
| Reviews | p. 174 |
| "Given enough eyeballs, all bugs are shallow" | p. 174 |
| Maintenance | p. 177 |
| The way to predict future maintenance costs and to make product replacement decisions is to look at past cost data | p. 177 |
| About Education | p. 181 |
| You teach people how to program by showing them how to write programs | p. 181 |
| Conclusions | p. 185 |
| About the Author | p. 189 |
| Index | p. 191 |
| Table of Contents provided by Syndetics. All Rights Reserved. |
ISBN: 9780321117427
ISBN-10: 0321117425
Series: Agile Software Development
Audience:
General
Format:
Paperback
Language:
English
Number Of Pages: 224
Published: 28th October 2002
Dimensions (cm): 23.5 x 18.7
x 1.2
Weight (kg): 0.342
9am - 4pm AEST, Monday - Friday
