The Limits of Software: People, Projects, and Perspectives

Britcher, Robert N.
Addison-Wesley
ISBN 0-201-43323-0
214pp
Date finished: 2004-03-13

An odd book, and one that I mostly didn't enjoy, though there are good bits in it. It starts out as a non-technical explanation of why software development is so difficult and of the techniques used to cope with its complexity. Chapter two is a good discussion of the hopes for formal methods, for example, written at about the level you'd use to explain it to someone at a party -- light style, lots of analogies, pays lots of attention to the personalities who came up with the idea. These nice properties make it entertaining, but so insubstantial that it's not of interest to anyone in the field who has even a vague acquaintance with the topic.

The book closes with a chapter describing the collapse of the FAA's Advanced Automation Project, which ran from 1981 to 1994 and never produced anything. Britcher describes several reasons for its failure: too much paperwork, too little testing, an overly ambitious distributed architecture, and of course the classic one, shifting requirements. For me this chapter is a startling glimpse into the over-managed world of government computer programming, where five requirements result in an 800-page page test plan; at one point Britcher says for every line of software 100 pages were written about it. (A friend of mine works for the government, and he spent the first 18 months on his job writing a design plan before writing a line of code. Then he started implementing and oops! a boss' boss has changed the requirements. So nothing changes...)

In the middle the book pretty much falls apart, crumbling into a jumbled collection of observations, boring anecdotes about people who may be fictional or not. The most amusing thing about this dismal stretch is the confused metaphors, which are often hilarious:

... indicating that this statement in this program can be traced to that program, which calls another, which is a refinement of this design statement, which can be said to be fathered by that requirement, which will be tested by this test. Think of capturing the relationship between the esophagus, stomach, and liver during a leisurely Italian meal. The relationships are liquid, more like wine than gnocchi.

Oh, of course, that makes it all clearer. Or:

There will be one. One great system. We will be swimming in it like plankton, with no apparent shoreline, no reference point, no place to land, no home base. Generations down the road will wonder how they came to float upon this digital wave.

Most of the book consists of poorly structured rambling like this, so on balance I don't recommend reading it. It's too vague for people in the field, and not interesting enough for people out of the field, who would be better off reading Danny Hillis' "The Pattern on the Stone".

Tagged: computing

Permalink: http://books.amk.ca/2004/03/Limits_of_Software.html

%T The Limits of Software
%S People, Projects, and Perspectives
%A Britcher, Robert N.
%@ 2004-03-13
%P 214pp
%G ISBN 0-201-43323-0
%I Addison-Wesley
%K computing

http://books.amk.ca

Contact me