Facts And Fallacies Of Software Engineering
Amazon claimed to have 6 used copies, but by the time I finished editing the page, none were available. Used copies are available again (March 2006).
A book by Robert L. Glass
- "This title offers 55 facts (and ten fallacies) that explore why software projects fail or succeed. Each fact is supported by insightful discussion and detailed references. The book identifies many of the key problems hampering success in the field of software engineering."
ISBN:0321117425
Table of Contents on Amazon: http://www.amazon.com/gp/reader/0321117425/ref=sib_rdr_toc/002-7061380-2593619?%5Fencoding=UTF8&p=S009#reader-link
Has anyone here read this book? What do you think?
Reviews:
- http://www.ercb.com/feature/feature.0069.html
- "Here is a sample of what I found particularly enlightening: "
- 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 (Fact 12).
- The answer to a feasibility study is almost always "yes" (Fact 14).
- Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical (Fact 22).
- Missing requirements are the hardest requirements errors to correct (Fact 25).
- One hundred percent [test] coverage is still far from enough (Fact 33).
- Better methods lead to more maintenance, not less (Fact 45), since "enhancements represent roughly 60 percent of maintenance costs" (Fact 42).
-
http://www.joelonsoftware.com/items/2003/11/14.html
- "the best summary of what the software profession should have agreed upon by now. Here are just a few examples from the 55 facts and 10 fallacies in 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.
- Adding people to a late project makes it later. [from Brooks, obviously]
- ReuseInTheSmall (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.
- ReuseInTheLarge (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.