Book Review: Facts and Fallacies of Software Engineering

Category:UncategorizedTag: :

image

Having this book on my shelf for quite some time now, I finally decided to to make my way through reading Facts and Fallacies of Software Engineering written by Robert L. Glass. As the title already implies, this well-established author lays down 55 facts and 10 fallacies about software engineering based on his half a century experience in the field.

The facts are divided in four categories: management, lifecycle, quality and research. The fallacies are split into three categories: management, lifecycle and education. Each of these categories have their own more specific sub-categories in which these facts and fallacies are classified. This way its easy to pickup the content about a particular topic of choice. Although I read the book from cover to cover, it isn?t required to do so. All facts and fallacies can be read on their own but occasionally the author refers to the discussion of other facts/fallacies in the book.

All facts and fallacies are laid down using the following structure:

  • The fact/fallacy itself is presented and discussed.
  • After which the controversies about a particular fact/fallacy are presented.
  • Finally, a list of books and articles are enumerated that were a source of information regarding the fact/fallacy. Some of these sources are ancient, some are more recent.
    Here?s the list of facts:

People

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

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

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

  18. Reuse-in-the-small is a solved problem.
  19. Reuse-in-the-large remains a mostly unsolved problem.
  20. Reuse-in-the-large works best in families of related systems.
  21. Reusable components are three times as hard to build and should be tried out in three different settings.
  22. Modification of reused code is particularly error-prone.
  23. Design pattern reuse is one solution to the problems of code reuse.
  24. Complexity

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

  28. One of the two most common causes of runaway projects is unstable requirements.
  29. Requirements errors are the most expensive to fix during production.
  30. Missing requirements are the hardest requirements errors to correct.
  31. Design

  32. Explicit requirements ‘explode’ as implicit requirements for a solution evolve.
  33. There is seldom one best design solution to a software problem.
  34. Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.
  35. Coding

  36. Designer ‘primitives’ rarely match programmer ‘primitives’.
  37. COBOL is a very bad language, but all the others are so much worse.
  38. Error removal

  39. Error removal is the most time-consuming phase of the lifecycle.
  40. Testing

  41. Software is usually tested at best to the 55 to 60 percent coverage level.
  42. One hundred percent test coverage is still far from enough.
  43. Test tools are essential, but rarely used.
  44. Test automation rarely is. Most testing activities cannot be automated.
  45. Programmer-created, built-in debug code is an important supplement to testing tools.
  46. Reviews and Inspections

  47. Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
  48. Rigorous inspections should not replace testing.
  49. Post-delivery reviews, postmortems, and retrospectives are important and seldom performed.
  50. Reviews are both technical and sociological, and both factors must be accommodated.
  51. Maintenance

  52. Maintenance typically consumes 40 to 80 percent of software costs. It is probably the most important software lifecycle phase.
  53. Enhancements represent roughly 60 percent of maintenance costs.
  54. Maintenance is a solution– not a problem.
  55. Understanding the existing product is the most difficult maintenance task.
  56. Better methods lead to more maintenance, not less.
  57. Quality

  58. Quality is a collection of attributes.
  59. Quality is not user satisfaction, meeting requirements, achieving cost and schedule, or reliability.
  60. Reliability

  61. There are errors that most programmers tend to make.
  62. Errors tend to cluster.
  63. There is no single best approach to software error removal.
  64. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
  65. Efficiency

  66. Efficiency stems more from good design than good coding.
  67. High-order language code can be about 90 percent as efficient as comparable assembler code.
  68. There are tradeoffs between optimizing for time and optimizing for space.
  69. Research

  70. Many researchers advocate rather than investigate.

And the list of fallacies:

Management

  1. You can’t manage what you can’t measure.
  2. You can manage quality into a software product.
  3. People

  4. Programming can and should be egoless.
  5. Tools and Techniques

  6. Tools and techniques: one size fits all.
  7. Software needs more methodologies.
  8. Estimation

  9. To estimate cost and schedule, first estimate lines of code.
  10. Testing

  11. Random test input is a good way to optimize testing.
  12. Reviews

  13. “Given enough eyeballs, all bugs are shallow”.
  14. Maintenance

  15. The way to predict future maintenance costs and to make product replacement decisions is to look at past cost data.
  16. Education

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

Although this book has been published in 2004, the topics that are discussed in this book very much apply today and probably many years to come. I personally got the most from the facts about people, estimation, testing and maintenance. I really enjoyed reading this fascinating book and I encourage you to pick it up as well. Awareness of these facts and fallacies, whether you agree or disagree with them,? is the first step to improving our craft.

9 thoughts on “Book Review: Facts and Fallacies of Software Engineering

  1. I’m not entirely sure that listing all the ‘headlines’ of the book’s content really counts as fair use; are you?

  2. I have not read this book, but from your description I think this book would be more interesting if it was based on facts (actual data) and not his experience in the industry (one data point).

    Can you not manage quality into a software product ? I not so sure. It obviously depends on the management and the team, but I think management is an important part of it. One thing is for sure, poor management can easily stop a great product from being created.

    It would be really interesting to see actual historical data on this.

  3. The 28 times figure is one of the most quoted facts from the book. I’m not exactly crazy about using a ratio of the minimum and the maximum. It is only two data points. Is that figure at all useful?

    I’d rather do a comparison against say the mean and the 95th percentile. A statement like “the top 5% of programmers is more than X times more productive than the average programmer” would much more meaningful.

  4. Who, amongst the readers of this article, did NOT already know and suffer through these obvious facts and fallacies ?

    Who was the book for ? What was the book for ? It seems like a “top ten” list that got published. Was there more to it than that bland nothingness ?

Comments are closed.

Find me

RSS
Facebook
Twitter
LinkedIn

Disclaimer

The opinions and content expressed here are my own and not those of my employer.