Robert L. Glass
Facts:
- The most important factor in software work is the quality of the programmers.
- The best programmers are up to 28 times better than the worst programmers.
- Adding people to a late project makes it later.
- The working environment has a profound impact on productivity and quality.
- Hype (about tools and techniques) is the plague on the house of software.
- New tools/techniques cause an initial loss of productivity/quality.
- Software developers talk a lot about tools, but seldom use them.
- One of the two most common causes of runaway projects is poor estimation.
- Software estimation usually occurs at the wrong time.
- Software estimation is usually done by the wrong people.
- Software estimates are rarely corrected as the project proceeds.
- It is not surprising that software estimates are bad. But we live by them anyway.
- There is a disconnect between software management and their programmers.
- The answer to a feasibility study is almost always "yes".
- Reuse-in-the-small is a well-solved problem.
- Reuse-in-the-large remains a mostly unsolved problem.
- Reuse-in-the-large works best for families of related systems.
- Reusable components are three times as hard to build, and should be tried out in three settings.
- Modification of reused code is particularly error-prone.
- Design pattern reuse is one solution to the problems of code reuse.
- 25 percent increase in problem complexity is a 100 percent increase in solution complexity.
- 80 percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
- One of the two most common causes of runaway projects is unstable requirements.
- Requirements errors are the most expensive to fix during production.
- Missing requirements are the hardest requirements errors to correct.
- Explicit requirements "explode" as implicit (design) requirements for a solution evolve.
- There is seldom one best design solution to a software problem.
- Design is a complex, iterative process. Initial design solutions are usually wrong, and not optimal.
- Designer "primitives" (solutions they can readily code) rarely match programmer "primitives".
- COBOL is a very bad language, but all the others (for business applications) are so much worse.
- Error-removal is the most time-consuming phase of the life cycle.
- Software is usually tested at best at the 55-60 percent (branch) coverage level.
- 100 percent coverage is still far from enough.
- Test tools are essential, but many are rarely used.
- Test automation rarely is. Most testing activities cannot be automated.
- Programmer-created, built-in, debug code is an important supplement to testing tools.
- Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
- But rigorous inspections should not replace testing.
- Post-delivery reviews (some call them "retrospectives" ) are important, and seldom performed.
- Reviews are both technical and sociological, and both factors must be accommodated.
- Maintenance (most important phase) consumes 40-80 percent of software costs.
- Enhancements represent roughly 60 percent of maintenance costs.
- Maintenance is a solution, not a problem.
- Understanding the existing product is the most difficult task of maintenance.
- Better methods lead to MORE maintenance, not less.
- Quality IS: a collection of attributes.
- Quality is NOT: user satisfaction, meeting requirements, achieving cost/schedule, or reliability.
- There are errors that most programmers tend to make.
- Errors tend to cluster.
- There is no single best approach to software error removal.
- Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
- Efficiency stems more from good design than good coding.
- High-order-language code can be about 90 percent as efficient as comparable assembler code.
- There are tradeoffs between size and time optimization.
- Many researchers advocate rather than investigate.
Fallacies
- You can't manage what you can't measure.
- You can manage quality into a software product.
- Programming can and should be egoless.
- Tools and techniques: one size fits all.
- Software needs more methodologies.
- To estimate cost and schedule, first estimate lines of code.
- Random test input is a good way to optimize testing.
- "Given enough eyeballs, all bugs are shallow".
- The way to make product replacement decisions is to look at past cost data.
- You teach people how to program by showing them how to write programs.
Facts and Fallacies of Software Engineering
ReplyDeleteby Robert L. Glass
Original title:
Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering
The F-Book
Book Review: Facts and Fallacies of Software Engineering
ReplyDeleteReviewed by Dwayne Phillips
http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/CUJ/2003/0307/cujweb0307phillips/index.htm
In Facts and Fallacies of Software Engineering, veteran practitioner and author Robert L. Glass discusses “Fifty-five frequently forgotten fundamental facts (and a few fallacies) about software engineering.” That was Glass’ first choice for the book’s title. (His second choice was The F-Book.) Glass combines humor, academic research, lessons from the school of hard knocks, and forty-five years of experience to lay out items that people who build and maintain software should know and remember.
Some of the facts in the book have almost universal agreement. For example, Fact #1 states, “The most important factor in software work is the quality of the programmers.” Some facts seemed strange at first glance. After reading the discussion, however, I had to agree with them. For example, Fact #45 states, “Better methods lead to more maintenance, not less.” Some of the facts that are so important that I should burn them into my memory. The two that I feel fit in this category are Fact #8 and Fact #23. They state that the two most common causes of runaway projects are (#8) poor estimation and (#23) unstable requirements.
Some of the facts caused me to stop reading and start arguing. Glass admits that his book contains controversial items — things that bring virulent debate. For example, Fallacy #8 states, “Given enough eyeballs, all bugs are shallow.” This is a mantra of the open-source software movement, and Glass says it is not so! Well, what he says is that no one has performed a study that proves the statement is true.
I paid attention to the material in this book because of its author. Glass has been in the software field for 45 years and has moved between industry and academia several times. He has written 25 books and has had regular columns in some of the most prestigious software journals. (He currently has a column in IEEE Software.)
Glass thoroughly covers each fact and fallacy. He has a template and he uses it without exception. I have read other books that attempt to use such a template style and fail. The template didn’t fit, and those books contained many sections with the equivalent of N/A (not applicable). That doesn’t happen in Glass’s book. The template is appropriate, and the author uses it well.
The facts and fallacies cover the spectrum of software engineering subject areas. They include people, tools and techniques, life-cycle activities, and even academic research and software engineering education. I like the way Glass distributes the facts and fallacies among the subject areas. He devotes five facts to maintenance (my favorite topic). He only has two facts about coding, but several of the other facts relate closely to coding. There is something in the book for almost everyone. I believe that is one of the strong points of the book. If you work in area X, you will find something in the book that relates closely to your job.
I found two topics missing in the book. The first is outsourcing. It seems that everyone is outsourcing work to another country or at least to another company. It would be helpful to have one or two facts about this. For example, “Given the amount of money spent on travel and communication infrastructure, outsourcing will only save a project X%.” The second topic concerns people trying to work together. For example, “People have strong emotions about their work in software, so learning to think clearly in the presence of strong emotions is a topic that educators should address.”
This book is organized well. The author divides the book into two main sections: Facts and Fallacies. The Facts section lists 55 items the author believes to be true. The Fallacies section lists 10 items that the software community has accepted, but the author believes to be false. Each fact or fallacy includes 1) a Discussion section, 2) a Controversy section, 3) a Sources section, and 4) a References section.
ReplyDeleteThe organization of the book helped me read and refer to the material. Before reading the book cover to cover, I flipped through the table of contents, jumped to a fact or fallacy that caught my eye, and spent ten minutes studying it. Since reading the book, I have kept it close at hand as a reference. When a topic comes up at work, I can easily grab the book, find the topic, and state a fact with data to justify it.
The material in this book is opinion backed by research. Glass shows the academic side of his career by providing sources of his information and references to other information. For example, Glass bolsters Fact #8 (“One of the two most common causes of runaway projects is poor estimation”) with four sources of information and three additional references. The sources and references remove the folklore from this book. Without them, Glass’s facts and fallacies would only be a collection of pithy sayings. With them, Glass’s material becomes something to use to make business decisions.
The book, however, is not a dry academic recitation of “fact, fact, fact, reference, reference, reference, my argument is air tight, so let’s move on.” Glass mixes in examples from his and others’ experience. One case is with Fact #13, “There is a disconnect between management and their programmers.” Glass relates the story of a project where a team developed software to control a medical instrument. Management deemed the project a failure as it was 400% over budget and 200% over schedule. The development team felt it was a great success because the software met all requirements (it worked and had no major defects on release), it was a technical challenge, and the team was small and high performing.
The audience for this book includes anyone who is interested in building software. I think it leans more towards managers and senior programmers than towards students and lesser experienced programmers. I say this because this is a “what-is” not a “how-to” book. It does not teach how to create a schedule for a project. Instead, it states Fact #3, “Adding people to a late project makes it later.”
The book does not teach debugging techniques. Instead, it states Fact #31, “Error removal is the most time-consuming phase of the life cycle.” The book, however, does contain material suitable for those readers who are newer to the field. Staying with Fact #31, “newbies” shouldn’t bet “grizzled old-timers” that their software is defect-free. Glass’s discussion will save newbies the expense of a lot of lunches.
The style Glass uses in this book is good for the intended audience. I found myself having a conversation with Glass. I would read a few sentences and think, “Oh yeah? Let me tell you something.” Then I would read a few more sentences and Glass would answer my objections as if we were in a room together. Glass does not come across as someone reading facts that are written in stone. He is skeptical about much of the folklore of the software community and clearly expresses that skepticism. He encourages people to be skeptical about what they hear; that includes being skeptical about what they read in his book. He states this loudly in Fact #55, “Many researchers advocate rather than investigate.” This fact is aimed at university researchers, but I interpret it as a warning to practitioners as well. We all need to remove some hype (“We think our idea is great.”) from our statements and add a few facts (“We did five projects with method A, six projects with method B, and reduced post-release defects by 10%.”)
ReplyDeleteI enjoyed reading this book. It taught me some new lessons, reminded me of some old ones, and caused me to think. The biggest value of the book has come since reading it. The facts and fallacies, along with the background material that Glass provides, helps me in my job. For example, when I recently recommended a large budget for the maintenance of a software system, someone challenged, “I thought we paid someone to write the software. Why do we have to keep paying them for the next three years?”
I opened Glass’ book, turned to Fact #41, and read, “Maintenance typically consumes 40 to 80 percent of software costs.” I could cite several references to support the fact. And I don’t give this example to show that I won an arugment or that I’m smarter than anyone else. It shows that this book helps my organization and me develop and maintain software better. I feel that’s a pretty good endorsement for a book.