Facts and Fallacies of Software Engineering - Book Review

home · about · subscribe

February 11, 2017 · -

I read Facts and Fallacies of Software Engineering and I quite enjoyed it. I enjoyed so much that I wanted a review and wanted to write down the quotes that I took.

The author is very knowledgeable and he knows his stuff, at least you can get the confidence that he knows his stuff. While I was reading the book, at some point, I said out loud “This is my people” the author and the audience. This does not happen very frequently and even when I read software related books.

“This” refers to software people and specifically; engineers that are working in the software industry. These people are the ones that are writing the software, preparing the meal in the kitchen, they know how that meal is made, they know what needs to be done to make it happen. They saw the sweet sweat to make that feature ship.

Most people are saying a lot of things about software. Software is eating the world, software is going to change a bunch of industries, software is revolutionizing how we do business, etc. Software is a relatively new field, there are going to be big opportunities and business people are speculating on this field is not the worst thing in the world. However, what I would like to hear more is from people in the kitchen. Not the people who are selling, not the people who are advertise(market), not the people who invest, not the people who manage. I want to hear people who are preparing the meal. I would like to hear how the preparation process is happening and how that process can be improved. So much for the kitchen analogy.

The book is a very easy read and well separated into various facts and fallacies. So, you can read one-two facts at a time. It is also a great example in the software field to be able to understand the software much better since the author is knowledgeable quite a bit in the area.

However, he has also a lot of biases and fallacies as well. First and foremost, the supporting facts to his point are given in a much more detailed way where he is not very meticulous about counter arguments. Also, some of his supporting facts is either from his personal experience or very “anecdotal”. While he is arguing some of the facts and fallacies are nothing but subjective opinions, he is supporting some of the “facts” in a very similar way.

Even though it has quite a few shortcomings, while reading the book, one can sense that most of the things in the book are learned in the kitchen, which itself is a reason to buy this book.


Maintenance, Maintenance, Maintenance

This is the stage which starts where you push the button to deploy the code into production. And it just never ends. You build features in this stage on top of the existing the codebase, you still need to fix bugs that is in the code, you still need to do a lot of work to be able to make it not break whether to accommodate various software dependencies or to accommodate a change in the downstream service.

This book gives a special importance on the maintenance in the software which is very well deserved. Most of the software engineers spend quite a bit of time in this stage of software development, but this is also the area where most of the time is spent. Technical debt shines in this stage of the software and arguably why this stage requires a large amount of time as well. Legacy code first needs to be read and understood; and this in technical debt is not very easy thing to do.


When you read the book, you can say that “this is my people” for the audience. Complaints around time estimation and how they are being done by non-engineer teams, how estimation of projects is always wrong in some measure, why projects can fail time after time, everything that an engineer could complain about software projects is here. It feels back in the school only difference, these time, adults are the the ones who are complaining.

Some Good Quotes

Seven Attributes for Quality Software

Life-Cycle of Software


  1. The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.
  2. The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.
  3. Adding people to a late project makes it later.
  4. The working environment has a profound impact on productivity and product quality.
  5. Hype is the plague on the house of software. Most software tool and technique improvements account for about 5 to 35 percent increase in productivity and quality. But at one time or another, most of those same improvements have been claimed by someone to have “order of magnitude” benefits.
  6. Learning a new tool or technique actually lowers programmer productivity and product quality initially. The eventual benefit is achieved only after this learning curve is overcome. Therefore, it is worth adopting new tools and techniques, but only if their value is seen realistically and if patience is used in measuring benefits.
  7. Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.
  8. One of the two most common causes of runaway projects is poor estimation.
  9. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that estimates are obtained before the requirements are defined and thus before the problem is understood. Estimation, therefore, usually occurs at the wrong time.
  10. Most software estimates are made either by upper management or by marketing, not by the people who build the software or their managers. Estimation is, therefore, done by the wrong people.
  11. Software estimates are rarely adjusted as the project succeeds. Thus those estimates done at the wrong time by the wrong people are usually not corrected.
  12. Since estimates are so faulty, there is little reason to be concerned when software projects do not meet estimated targets. But everyone is concerned anyway.
  13. There is a disconnect between management and their programmers. In one research study of a project that failed to meet its estimates and was seen by its management as a failure, the technical participants saw it as the most successful project they had ever worked on.
  14. The answer to a feasibility study is almost always “yes”.
  15. Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.
  16. Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.
  17. Reuse-in-the-large works best in families of related subsystems and thus is domain dependent. This narrows the potential applicability of reuse-in-the-large.
  18. There are two “rules of three” in reuse:
  1. Modification of reused code is particulary error-prone. If more than 20 to 25 percent of a component is to be revised, it is more efficient and effective to rewrite it from scratch.
  2. Design pattern reuse is one solution to the problems inherent in code reuse.
  3. For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of software solution. That is not a condition to try to change(even though reducing complexity is always a desirable thing to do) that is the just way it is.
  4. Eighty percent of software work is intellectual. A fair amount is creative. Little of it is clerical.
  5. One of the two most common causes of runaway projects is unstable requirements.(See Fact 8 for other cause)
  6. Requirements errors are the most expensive to fix when found during productioni but the cheapest to fix early in the development.
  7. Missing requirements are the hardest requirements errors to correct.
  8. When moving requirements to design, there is an explosion of “derived requirements” (the requirements for a particular design solution) caused by the complexity of the solution process. The list of these design requirements is often 50 times longer than the list of original requirements.
  9. There is seldom one best design solution to a software problem.
  10. Design is a complex, iterative process. The initial design solution will likely be wrong and certainly not optimal.
  11. Programmers shift from design to coding when the problem is decomposed to a level of “primitives” that the designer has mastered. If the coder is not the same person as the designer, the designer’s primitives are unlikely to match the coder’s primitives, and trouble will result.
  12. COBOL is a very bad language, but all others (for business data processing) are so much worse.
  13. Error removal is the most time consuming phase of the life cycle.
  14. Software that a typical programmer believes to be thoroughly tested and has often had only about 55 to 60 percent of its logic paths executed. Using automated support, such as coverage analyzers, can raise that roughly 85 to 90 percent. It is nearly impossible to test software at the level of 100 percent of its logic paths.
  15. Even if 100 percent test coverage were possible, that is not a sufficient criterion for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent from the execution of a unique combination of logic paths. They will not be caught by 100 percent coverage.
  16. It is nearly impossible to do a good job of error removal without tools. Debuggers are commonly used, but others, such as coverage analyzers, are not.
  17. Test automation rarely is. That is, certain testing processes can and should be automated. But there is a lot of the testing activity that cannot be automated.
  18. Programmer-created built-in debug code, preferably optionally included in the object code based on compiler parameters, is an important supplement to testing tools.
  19. Rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run.
  20. In spite of the benefits of rigorous inspections, they cannot and should not replace testing.
  21. Postdelivery reviews(some call them “retrospectives”) are generally acknowledged to be important, both from the point of view of determining customer satisfaction and from the point of process improvement. But most organizations do not do postdelivery reviews.
  22. Peer reviews are both technical and sociological. Paying attention to one without the other is a recipe for disaster.
  23. Maintenance typically consumes 40 to 80 percent(average, 60 percent) of software costs. Therefore, it is probably the most important life cycle phase of software.
  24. Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.
  25. Maintenance is a solution, not a problem.
  26. In examining the tasks of software development versus software maintenance, most of the tasks are the same - except for the additional maintenance task of “understanding the existing product”. This task consumes roughly 30 percent of the total maintenance time and is the dominant maintenance activity. Thus, it is possible to claim that maintenance is a more difficult task than development.
  27. Better software engineering development leads to more maintenance, not less.
  28. Quality is a collection of attributes: portability, reliability, efficiency, usability, testability, understandability, and modifiability.
  29. Quality is not user satisfaction, meeting requirements, meeting costs and schedule targets, or reliability.
  30. There are errors that most programmers tend to make.
  31. Errors tend to cluster.
  32. There is no single best approach to software error removal.
  33. Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
  34. Efficiency stems more from good design than from good coding.
  35. High-order language(HOL) code, with appropriate compiler optimizations, can be about 90 percent as efficient as the comparable assembler code. Or even higher, for some complex modern architectures.
  36. There are tradeoffs between size and time optimization. Often, improving one degrades the other.
  37. Many software researchers advocate rather than investigate. As a result, some advocated concepts are worth far less than their advocates believe, and there is a shortage of evaluative research to help determine what the value of such concepts really is.


Reality is the murder of a beautiful theory by a gang of ugly facts.

As reality, software is the murder of a beautiful theory by a gang of ugly facts.

All Rights Reserved

Copyright, 2020