Customer Reviews

The Limits of Software: People, Projects, and Perspectives

5 star:		(8)
4 star:		(3)
3 star:		(1)
2 star:		(0)
1 star:		(2)

 

 

The same task has produced what is arguably the greatest triumph as well as the greatest failure in software development. Air traffic control is a task where 24/7/365 (functional 24 hours a day, 7 days a week, 365 days a year) must be a law rather than a mantra. The national air traffic control computer system known as the 9020 was written using punched cards and is roughly 500,000 lines of code. Despite all the noise about problems and obsolescence, it has scaled up so well that it is used to control several times the number of flights that it did when it was developed in the seventies. The project to replace it, called the Advanced Automation System, cost several billion dollars and yielded nothing usable, although it did make the developers a great deal of money. Within these two extreme bookends there are several lessons to be learned and that is the point of this book.
The author worked on the 9020 system and spends a great deal of time ruminating on how things were, from coding to the personalities of those who built it. Packed within this is one clear lesson. In all successful software projects, there is a small, core group of people who do the bulk of the true work. Enlarge that core, either by increasing the numbers or infiltrating it with bureaucracy, and the chances of failure plummet. This is the conclusion reached by the author in his analysis of why the Advanced Automation System failed. The secondary lesson is that the very stability of the air traffic control system makes it fragile and difficult to change. There is no easy way to make changes to the system, where the simple movement of a control knob several inches can create problems.
There are lessons for developers sprinkled throughout the book, although it is sometimes necessary to read carefully to find them. Presented in the form of a non-sequential journal, the flow sometimes goes sideways, but it nearly always manages to make a valid point.

The Limits of Software is eccentric and eloquent. I've never read anything quite like it. Somehow the author has mixed amusing stories, characters and dialogue, and technical material in the right proportion: the book is not just informative, at times it is moving. The book, at 200 pages, reads like a 20-page article; but it lingers like a fine novel.

This work by the author provides an excellent narrative on software development issues from the perspective of those actually doing the development. The experiences described are typical of those lived by many software developers. The book is easy to read and captures the reader in the intensity of the authors experiences.

This is one of the finest books on any subject I have ever had the pleasure of reading. In fact, a savvy publisher might have taken the words in this book, combined them with some high-quality photography, and converted it into a glossy-paged coffee table book without much effort. But alas, we lucky few who have read it will have to do without the stage-dressing, and console ourselves with the beauty of the words themselves.

This certainly isn't a "How-To" book, or a quick punch-list to make you a better manager. Rather, it is a thin volume of lyric beauty; a poem to the design and management of software. I would have thought our industry too young yet for a work like this, but Robert Britcher has cobbled together flashes of life from the computing industry ranging from the 60's through the late 90's into a sum larger than its parts.

Will reading this book make you a better manager or engineer? I think so -- if only by helping to create a shared history of the software industry, and a vivid and visceral set of lessons from the front lines.

The insights and recollections in these essays at first discouraged me - as my naive hopes (that software and standards could tame any problem) were dashed.

That discouragement (mostly) disappeared when I realized the author was using "worst cases" to make his points clear.

I was left with the realization that reasonable people, working on reasonable projects using reasonable rules can accomplish much.

I started reading this book over dinner, couldn't put it down, and ended up finishing it that night. Britcher presents a perspective on computing that is refreshingly different from the usual technocratic point of view. It is nice to see someone who worries about the ethics of this industry for a change, and who doesn't subscribe to the idea that if something is computerized, it must automatically be better. Lot's of thoughtful comments about the state of the industry, software engineering, management, and the psychology and ethics of computing.

Highly recommended!

At one level, this is a wonderful book about engineering, but there is more to it than that. It's about how we behave in the face of technology, especially those of us who are deeply involved in it. The book is important; I hope it is discovered.

I can't stress enough how enjoyable the book was to read. The stories used throughout the book can easily be appreciated by software developers and software hobbyist alike. How refreshing it was to read about the trials and tribulations of real world software development. Perhaps this should be required reading at all universities.

Mr. Britcher has written a fine book that at times is a little difficult to follow where he is going. Having worked on our National Air Traffic Control System myself for nearly 25 years I could relate too many of his stories. Software engineering by it very nature can bog down very quickly in the tools used to arrive at a do-able solution. His best points are about the difficulty of rewriting something writen so well and back in the days when you had to sweat using too much storage. That being the case the system is easy to maintain and has scaled "up" countless times over the last three deades. The system was re-platformed in 1998 onto hardware that offered five nines of reliability. Normally when you place an operating system and applications on the hardware the total system reliability suffers.In case of the system Mr. Britcher cites as the the target for replacement reliability stayed at five nines on a system 24x7x365, as it does at this very instant.

I only wish every FAA manager would read Mr. Britchers book because they are about to commit the same mistake they did on AAS only this time it is called ERAM. Large corporations evolve systems, ie Microsoft Windows Operating System built one release on the other. The government on the other hand replaces systems because that becomes a "program" and employes thousands of government workers.

Unfortunitly everything Mr. Britcher writes about AAS is about to happen again on ERAM. With us the American tax payers the big losers and a few corporations who get paid no matter what, the big winners.

Thank you Mr. Britcher for putting into words what I see happening around me every working day, it is a very timely read.

Bill Capo

I feel like slaming this book. It contains a series of lightly connected stories. There is very little real information about what went wrong with the project or anything else. However, it is interesting; I read it in two sittings. My advise is to check it out of the library in a year or two. Don't spend money on this book.