Rating: 
Summary: A beautifully written book.
Review: 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.
Rating:
Summary: Britcher's personal style of writing is very refreshing!
Review: The Limits of Software is the most human piece of literature on the topic of technology that I've encountered.
Rating: 
Summary: pompous joke
Review: 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.
Rating: 
Summary: An analysis of a major success and a major failure
Review: 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.
Rating:
Summary: pompous joke
Review: This book is like the emperor's new clothes -- if you aren't carried away by the brilliantly obscure allusions, you must be poorly educated. Ok. I'll be the one stupid enough to say "uh, excuse me, but...". I bought this book believing the title was serious, and that the blurb (and forward) by Robert Glass had some meaning. I'm actually embarrassed by how far into the book I got before I finally realized I'd been totally "had". I thought the obscure references must have more meaning than I was literate enough to get. In fact, there is no real content to this book. There's nothing but tease. It flits around, goes off on silly tangents, but never actually gets to any meat about "the limits of software". I've bought a lot of computer science-related books from Addison Wesley over the last 30 years, and I'm very surprised, and disappointed, that they published this tripe.
Rating:
Summary: A work of art
Review: 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.
Rating:
Summary: A work of art
Review: 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.
Rating:
Summary: An excellent narrative of software development issues.
Review: 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.
Rating: 
Summary: The Limits of Software - An Interview With The Author
Review: Why did you write this book? The book evolved from articles and lectures. For years I've tried to make sense of and put words to the nature of programming and software. Symbol-writing in the interest of production is complex, whether the symbols represent molecules, atoms, logic, or words. The environment is somewhat enigmatic and at times surreal. The book is one set of symbols describing the making of another set - computer programs. So the book is somewhat enigmatic and, at times, surreal. Who do you see buying this book? I think people interested in technology, in general, and software, in particular, would enjoy the book. Engineers, programmers, managers, users: all will find in it some corner of their own experience. What is the importance of this book? I hope the general reader will better understand what is involved in producing software so that he or she will be more alert to its side effects as well as its benefits. For the practitioners and those involved professionally in software, the book asks What are we doing and why? and How are we doing it? What do you think is going to happen in Y2K? Are we in trouble? I suspect that there will be failures, but there will also be recovery. Maybe we'll even learn something about ourselves. Failures can do that. I have no doubt that the secondary effects -- investigations, media attention, fault-finding -- will overshadow even the worst failures. Personally, I'd be more worried about the canisters of smallpox kept in freezers in North Korea, Iran, China, and a dozen other states. What do you see as the future of software engineering? The consumer's standards drive the producer's techniques. Humans adapt quite readily to deprivation. But if the pain becomes severe enough, we demand that something be done. Recently, we have been in a rush to build, buy, and sell software. I hope that the software market, in the public and private sectors, will edge towards higher quality - with a nudge or two from advocates. This should drive an increase in and more widespread use of engineering principles. Over centuries we've learned that the articles that last are those that have been professionally engineered.
|
