The very brilliant, Facts and Fallacies of Software Engineering

This has to be one of the best software books I have ever read.

Why you might ask, well:

• Its short, a mere 184 pages
• It contains actual facts, not just opinions.
• It contains useful actual facts.
• It isn’t tied to any particular technology with a half life of a fruit fly (e.g. Teach Yourself Java in 21 Minutes)

So without further a do, I present the contents, a list I shall be referencing many times in the future.

55 Facts
ABOUT MANAGEMENT
PEOPLE
Fact 1	The most important factor in software work is the quality of the programmers.
Fact 2	The best programmers are up to 28 times better than the worst programmers.
Fact 3	Adding people to a late project makes it later.
Fact 4	The working environment has a profound impact on productivity and quality.
TOOLS AND TECHNIQUES
Fact 5	Hype (about tools and techniques) is the plague on the house of software.
Fact 6	New tools and techniques cause an initial loss of productivity/quality.
Fact 7	Software developers talk a lot about tools, but seldom use them.
ESTIMATION
Fact 8	One of the two most common causes of runaway projects is poor estimation.
Fact 9	Software estimation usually occurs at the wrong time.
Fact 10	Software estimation is usually done by the wrong people.
Fact 11	Software estimates are rarely corrected as the project proceeds.
Fact 12	It is not surprising that software estimates are bad. But we live and die by them anyway!
Fact 13	There is a disconnect between software management and their programmers.
Fact 14	The answer to a feasability study is almost always “yes.”
REUSE
Fact 15	Reuse-in-the-small is a well-solved problem.
Fact 16	Reuse-in-the-large remains a mostly-unsolved problem.
Fact 17	Reuse-in-the-large works best for families of related systems.
Fact 18	Reusable components are three times as hard to build and should be tried out in three settings.
Fact 19	Modification of reused code is particularly error-prone.
Fact 20	Design pattern reuse is one solution to the problem of code reuse.
COMPLEXITY
Fact 21	For every 25 percent increase in problem complexity, there is a 100 percent increase in solution complexity.
Fact 22	Eighty percent of software work is intellectual. A fair amount of it is creative. Little of it is clerical.
ABOUT THE LIFE CYCLE
REQUIREMENTS
Fact 23	One of the two most common causes of runaway projects is unstable requirements.
Fact 24	Requirements errors are the most expensive to fix during production.
Fact 25	Missing requirements are the hardest requirements errors to correct.
DESIGN
Fact 26	Explicit requirements “explode” as implicit (design) requirements for a solition evolve.
Fact 27	There is seldom one best design solution to a software problem.
Fact 28	Design is a complex, iterative process. Initial design solutions are usually wrong and certainly not optimal.
CODING
Fact 29	Designer “primitives (solutions programmers can readily code) rarely match programmer “primitives.”
Fact 30	COBOL is a very bad language, but all the others (for business applications) are so much worse.
ERROR REMOVAL
Fact 31	Error removal is the most time-consuming phase of the life cycle.
TESTING
Fact 32	Software is usually tested at best 55 to 60 precent (branch) coverage level.
Fact 33	One hundred percent coverage is still far from enough.
Fact 34	Test tools are essential, but many are rarely used.
Fact 35	Test automation rarely is. Most testing activities cannot be automated.
Fact 36	Programmer-created, built-in debug code is an important supplement to testing tools.
REVIEWS AND INSPECTIONS
Fact 37	Rigorous inspections can remove up to 90 percent of errors before the first test case is run.
Fact 38	Rigorous inspections should not replace testing.
Fact 39	Postdelivery reviews (some call them “retrospectives”) are important and seldon perfromed.
Fact 40	Reviews are both technical and socialogical, and both factors must be accommodated.
MAINTENANCE
Fact 41	Maintenance typically consumes 50 to 80 percent of software costs. It is probably the most important life cycle phase of software.
Fact 42	Enhancements represent roughly 60 percent of maintenance costs.
Fact 43	Maintenance is a solution, not a problem.
Fact 44	Understanding the existing product is the most difficult task of maintenance.
Fact 45	Better methods lead to more maintenance, not less.
ABOUT QUALITY
QUALITY
Fact 46	Quality is a collection of attributes.
Fact 47	Quality is not user satisfaction, meeting requirements, achieveing cost and schedule, or reliability.
RELIABILITY
Fact 48	There are errors that most programmers tend to make.
Fact 49	Errors tend to cluster.
Fact 50	There is no single best approach to software error removal.
Fact 51	Residual errors will always persist. The goal should be to minimize or eliminate severe errors.
EFFICIENCY
Fact 52	Efficiency stems more from good design than from good coding.
Fact 53	High-order language code can be about 90 percent as efficient as comparable assembler code.
Fact 54	There are tradeoffs between size and time optimization.
ABOUT RESEARCH
Fact 55	Many researchers advocate rather than investigate.
5+5 Fallacies
ABOUT MANAGEMENT
Fallacy 1	You can’t manage what you can’t measure.
Fallacy 2	You can manage quality into a software product.
PEOPLE
Fallacy 3	Programming can and should be egoless.
TOOLS AND TECHNIQUES
Fallacy 4	Tools and tecniques: one size fits all.
Fallacy 5	Software needs more methodologies.
ESTIMATION
Fallacy 6	To estimate cost and schedule, first estimate lines of code.
ABOUT THE LIFE CYCLE
TESTING
Fallacy 7	Random test input is a good way to optimize testing.
REVIEWS
Fallacy 8	“Given enough eyeballs, all bugs are shallow.”
MAINTENANCE
Fallacy 9	The way to predict the future maintenance costs and to make product replacement decisions is to look at past cost data.
ABOUT EDUCATION
Fallacy 10	You can teach people how to program by showing them how to write programs.

~ by icantbelieveit on March 26, 2007.