Facts and Fallacies of Software Engineering

Keywords: Software development, development processes, RUP, XP

Title: Facts and Fallacies of Software Engineering

Author: Robert L. Glass

Publisher: Addison Wesley

ISBN: 0321117425

Media: Book

Verdict: Highly recommended, especially for hardened cynics

Buy US
Buy UK

How can you not fall in love with a book that states 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?. This is the first fact in Robert Glass's entertaining collection of Facts and Fallacies of Software Engineering. Of course it's a fact that everybody involved in software development is familiar with, but it is one that is also conveniently forgotten at times, particularly when it is contrasted with the twin Gods of Process and Tools. Tools we can control, or so we like to think. Process we can control, until it starts to control us. But people are messy, complicated and so damned expensive...

Of course, there is more to what Glass has to say than a bald statement of fact or fallacy. Each point - and he has 55 facts and 10 fallacies to relate - is the focus for a three or four page discussion of the issues, controversial ideas and historical perspectives and pointers to interesting references. This book is more like an anthology of mini-essays, and each is well written, light in tone but serious all the same. Put together this book provides more than enough food for thought.

The different facts are neatly aggregated into different categories: People, Tools and Techniques, Estimation, Re-use etc. All aspects of the development life-cycle are touched on to some extent - from design to coding to testing and so on. Similarly issues of quality, review and research are also addressed. The fallacies are grouped in the same way, though these are collected together in a separate section of the book rather than slotted into the same section as the facts.

The fallacies are a mixed bunch: Given enough eyeballs, all bugs are shallow, for example, strikes at the heart of the open source movement, which prides itself on peer review of code, beta testing and frequent bug-fix releases to achieve that elusive goal of software quality. If Glass is right, then the fallacy that lots of eyes poring over source code finds all bugs means that potentially trouble is being stored up for the future. Is he right? He's right about a lot of things, so perhaps this is one fallacy that demands our scrutiny.

As you might have gathered from the opening fact, there is a strong whiff of common-sense to this book. Hype is banished and Glass takes great delight in saying what needs to be said. In many ways there is a significant degree of commonality between his views and those found in some of the light-weight development processes, such as XP and the Agile development processes. What he says validates many of the ideas discussed by Alistair Cockburn in his excellent Agile Software Development: Software Through People, for example.

Some of the facts that are included here go back to the stone-age of software development. Adding people to a late project makes it later, for example, goes back to Fred Brooks and his classic The Mythical Man-Month, and it was probably old-hat even then. The fact that these issues are worth re-stating - and Glass restates them elegantly and effectively - should be telling us that despite huge advances in technology, we still don't know very much about how to best develop software.

In the preface Glass says of the facts he has collected: ?nearly all of them represent knowledge that we fail to act on. There's a lot here that had me wanting to shove a copy of the book under the noses of development managers everywhere. Buy this book and you'll be wanting to do the same.

Hit the 'back' key in your browser to return to subject index page

Return to home page