The Limits of Software

Thanks to Jason Bennett, who wrote this review of The Limits of Software. Robert N. Britcher explores in this book what software is and where software is going -- and what it really means.

The Limits of Software author Robert N. Britcher pages 214 publisher Addison Wesley rating 7 reviewer Jason Bennett ISBN 0-201-43323-0 summary Where we've been, where we're going, and the implications therein

Background

Before I launch into my latest review, I'd just like to say thanks to Hemos and Slashdot on the occasion of my twentieth review posted here. It's been 25 months since the first one (August, '98), and I've really appreciated the opportunity they've given me. Nice excuse to do something I should do anyway! :-)

The Scenario

"But it is not the practitioners alone who are so moved. A thousand years in the making, the religion of technology has become the common enchantment, not only of the designers of technology but also those caught up in, and undone by, their godly designs. The expectation of ultimate salvation through technology, whatever the immediate human and social costs, has become the unspoken orthodoxy, reinforced by a market-induced enthusiasm for novelty and sanctioned by a millenarian yearning for new beginnings. This popular faith, subliminally indulged and intensified by corporate, government, and media pitchmen, inspires an awed deference to the practitioners and their promises of deliverance while diverting attention from more urgent concerns. Thus, unrestrained technological development is allowed to proceed apace, without serious scrutiny or oversight -- without reason. Pleas for some rationality, for reflection about pace and purpose, for sober assessment of costs and benefits -- for evidence even of economic value, much less larger social gains -- are dismissed as irrational. From within the faith, any and all criticism appears irrelevant, and irreverent." (TLOS, xxiii)

-- David F. Noble, The Religion of Technology, as quoted in The Limits of Software

I had the privilege of spending a few weeks with a good friend of mine in Eastern Europe back in July. Of course, to go anywhere on a budget in Europe requires a lot of train travel. Alas, there are no bullet trains in Slovenia, which gave me plenty of time to take in some reading when I wasn't chatting with my fellow passengers ...

The Limits of Software is a unique book in many ways, not the least of which is that it reads more like a collection of life stories than a lecturing textbook. Most computer books simply give you data, or even information, in a straightforward manner, hopefully punctuated by some interesting anecdotes. Britcher, instead, has packaged with words slices of time which illustrate various points about where computer programming has been, and where software development is going (note the terminology change). I certainly won't try to describe them all, but theme which runs through the book is illustrated in the opening quotation: software is not our savior. There is no "one great system" that will be able to handle things. The FAA's botched air traffic control system is used as one illustration in the book, but the point is made about all software: we cannot and must not worship it.

There's one point that I find simultaneously funny and sad: It's in the chapter on testing, and the inherent futility of such an activity on complex programs. Britcher discusses the Y2K bug, and mentions the survivalist movement.

"Just as regular folks built bomb shelters in the 1950s and 1960s to add life time to a planet white with nuclear snow, regular folks are now storing large caches of food, water, toilet paper, clothing, and, of course, the American twinship: sacred literature and ammo. One man who agreed to be interviewed for the piece was quoted: 'When you first hear about it, most people are in total denial. They can't believe that Bill Gates won't come up with a magic bullet.' (That the general population believes that Bill Gates has the answers to our programming problems is more frightening than the rollover of the millennium.)" (TLOS, 59)

I quote this not as a shot at Bill (although, this being Slashdot, I'm sure some will take it that way), but to point out the inherent risks in the statement, which illustrate Britcher's point. Software is dangerous, because it does so much yet is so fragile. We (even we programmers at times) view it as a holy grail. We cannot understand how our mechanical saviors could possibly fail us. Yet, software failures are rampant, in every facet of our society (see the Risks Digest if you need examples). Software cannot solve our problems. Our problems are inherent within ourselves. As we continue to rely more and more on machines to live for us, we must remember that they, like their creators, are fallible. What's Bad? / What's Good?

When I finished TLOS, my first reaction was to think of the old saw about the life of a fighter pilot: "hours and hours of sheer boredom, punctuated by moments of sheer terror." Britchner's stories seemed to drone on at points. The FAA story was left to the end. Why did he have to go on and on about all this random stuff?

In retrospect, though, I think I have a better grasp of what Britcher was trying to convey. This is not a disaster movie told in the guise of software engineering; this is a story about one man's journey through software, and the conclusions he's come to. Read this as an technological autobiography, and I think you'll appreciate the points being made. As I said earlier, it's different, but rewarding in the end.

So What's In It For Me?

A reminder that the Tower of Babel still lives in the hearts and minds of men.

You can purchase this book at Fatbrain.

Table of Contents

• Foreware by Robert L. Glass
• Prologue
• Part I
  1. Early Systems
  2. Theories of Programming
  3. The Human Element
  4. Designing
  5. Code: The Stuff of Programs
  6. Testing Computer Systems
  7. The Impossible Profession
  8. Life on the Project
• Part II
  1. Supervision Through Language
  2. How Technology Changes Methods
  3. Size and Intellectual Gravity
  4. The Marketing of Science
  5. Errors
  6. The One Great System
  7. The Government of Programming
  8. The System to End All
  9. The End-All of Programming
• Afterward
• Reading List

Comments

Nice quote.

[Lonesmurf]

"hours and hours of sheer boredom, punctuated by moments of sheer terror."

funny, that's pretty much my life. :)

how about: "hours and hours of coding, punctuated by moments of delirium."

or: "hours and hours of sheer boredom, puctuated by lunch."

Rami
--

People never change

[FascDot Killed My Pr]

I bet there was some ancient Sumerian who gave long lectures on "The Limits of Literacy" warning that we shouldn't worship reading and writing--those skills can't make our lives better. Imagine his face if we were to show him a modern, industrialized nation.

It's a poor workman who blames his tools. If there is a way for an air-traffic to be controlled by a system, and your air-traffic control system doesn't do it, the reason is not inherent in the "limits of software"--there's some problem with your design/implementation. Software is a universal machine simulator--pure algorithms implemented as 1's and 0's. If that idea isn't worthy of awe I don't know what is.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/

Re:People never change

[wnissen]

It's a poor workman who blames his tools. If there is a way for an air-traffic to be controlled by a system, and your air-traffic control system doesn't do it, the reason is not inherent in the "limits of software"--there's some problem with your design/implementation.

I believe this misses the point of the book, at least judging from the quote by Prof. Noble. The point is, it's a poor workman who assumes his tools are all-powerful and not subject to normal criteria like cost/benefit analyses. The engineers who built cathedrals (no ESR metaphors intended here) used secret design principles painstakingly determined by trial and error through the centuries. If the building stayed up for hundreds of years, it was a Good Thing. Software is a young discipline, largely without solid rules, and yet is widely acknowledged to be changing the world. Software will drastically change the next generation of children, whose parents will prbably all have to use a computer at some point. There are what, a hundred million computers in the US? And yet the primary operating system on them is actively bad. Even Linux is often klunky, and despite better stability isn't even as easy to use as that mass of inconsistency, Windows. Why is this? Because the culture of software believes "good enough" really is good enough. Most people who become programmers are lucky if they get a few semesters of training learning different languages. They get no training at all in controlling the number of defects in their code. This results in lots of software of average quality, that is to say, shit.

A lot of this is driven by the fact that many people believe it is okay to admire software as math. It's not. Software is meant to accomplish something, and to do it better or faster or cheaper than however it was done before. It has absolutely nothing to do with pretty math, or purity, or any of those things you say are worthy of awe. If I designed a bridge with a novel way of laying out the supports that was really neat, but the bridge fell over because the supports interfered with the arches, no one would complement me on my support placement algorithm. They'd think I was an idiot who couldn't design a bridge to save his life. And yet I see all the time, "Wow, this code is really cool, it doesn't all work yet but isn't it neat?" because as long as it's software no one cares.

Walt

How Ironic

[guinsu]

I find it ironic that the opinion that technology can't solve our problems comes right after a story about Dean Kamen, who thinks technology can solve our problems.

My personal feeling is that it can solve a lot of our problems permanently (hunger, disease, etc) however it won't spontaneously happen, it does require people and their priorities to change too. If a large enough portion of this planet decided tommorow that clean burning engines, safe drinking water and better agriculture were the areas they wanted to focus research on instead of the latest electronics gadget, then eventually we would solve those problems. In a certain way, technology is the answer, but only if society puts effort/money into moving technology ina certain direction.

Re:The solution - use Formal Methods

[Philbert Desenex]

"Formal methods" sounds really great at first, as does "better quality". But each phrase contains so much hidden meaning that using them identifies you as someone who hasn't really thought about the issues at all. "Formal methods" falls down because using them assumes that we can specify accurately and precisely what the system should do. And you have to do that specification up front. Such exacting up front specification poses more of a problem than iterative development by service packs and patches. "Better quality" has no specific meaning. The American Society for Quality says: "Quality is a jubjective term for which each person has his or her own definition." This allows each of us, programmers, managers, salesmen or customers to "know" what quality is, and use the phrase informally. Then, when the rubber has to meet the road, you can't actually write code that represents "quality" because it doesn't exist except as a figment of some executive director's imagination.

A keen understanding of the obvious

[PHAEDRU5]

First, thanks for the review.

That said, humans are fallible. What can we expect but that the artifacts they create will also be fallible? There are assuredly limits on software - limits on computability - but the limits I see here are more limits on human ability to describe solutions to problems that become larger and larger as the simpler ones are mastered.

As for technology as religion, it's not religion to me, it's a source of comfortable living.

Now, if only I could stop my VCR from blinking "12:00....12:00...."

Anecdote to share

[Mindwarp]

Readng this review brought to mind an anecdote shared by an old professor of mine in a class discussing the need for completeness testing and mathematical proof of algorithms.

The incident related was to do with the testing of a new auto-pilot/terrain following system being installed on the Tornado fighter-bomber (the British air-to-ground attack aircraft). All was going well with the test flight until the aircraft dipped into a valley. Shortly after entering the valley the aircraft inverted and performed the classic 'lawn dart' manouver.

There was of course an insuing investigation and analysis of the auto-pilot software during which it was found that this exact behaviour would occur if the altimeter returned a negative value.

How could this happen? The valley was below sea level.

--

Re:Genocide? Hardly.

[FallLine]

Uh well. For one, most of the Amish live on some of the most fertile soil in the United States. Secondly, they're not entirely independent, they sell much of their wares so they can buy certain goods and services. Thirdly, it's a mistake to compare the Amish which support relatively small populations on large plots of land to the even small populations on even larger plots, because those farmers are generating most of the food for people in cities. The Amish simply don't need to produce nearly as much food per acre.

I don't quite get your argument about Kansas. Though I sincerely doubt the indians were able to support high population densities given their primitive agricultural skills, the fact is that Kansas EXPORTS most of their product. So that's a bogus analogy too. In any event, if the Amish lifestyle is so ideal, why don't you join them? I'm sure they'd take you.