I’m a bit torn on this book. On the one hand, it’s a wonderful collection of wisdom from many years in the software industry, backed with lots of sources, studies, and research. On the other hand, this wisdom is presented as a list of problems, with no attempt at offering any solutions to these problems. And it’s a long list. You can only listen to someone rant about everything that’s wrong with the software industry for so long before you tune out.
Within this laundry list of gripes, there are a few wonderful gems. This book would’ve been much more valuable if it had focused on just handful of these “facts”, going deeper on each one, and exploring solutions in addition to the problems. Alas, you have to skim the book quickly, and put in your own effort to hone in on the interesting tidbits, and skip over the rest.
As always, I’ve saved a few of my favorite quotes from the book:
“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.”
“The issue was, “If your life depended on a particular piece of software, what would you want to know about it?” Bollinger responded, “More than anything else, I would want to know that the person who wrote the software was both highly intelligent, and possessed by an extremely rigorous, almost fanatical desire to make their program work the way it should. Everything else to me is secondary. . . .””
“Most software tool and technique improvements account for about a 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.”
“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.”
“The answer to a feasibility study is almost always “yes.””
“For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing to do); that’s just the way it is.”
“When moving from 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.”
“Fact 33: 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.”
“The concentration needed to do a good technical review job tends to diminish the amount of attention we pay to the social aspects of the review. During most of our social activities, a certain percentage of our being is devoted to the topic in question, and the remainder is devoted to making the social relationship work. At a software review, that becomes difficult. The focus needed to achieve rigor eats away at the energy we have left to work the social issues. And the social issues during a review can be profound.”
“Fact 41: 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.”
“Fact 44: 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.”
Rating: 3 stars
Yevgeniy Brikman
If you enjoyed this post, you may also like my books. If you need help with DevOps, reach out to me at Gruntwork.