Skip to main content
No. 442:
Designing Software

Today, let's talk about responsibility and accountability. The University of Houston's College of Engineering presents this series about the machines that make our civilization run, and the people whose ingenuity created them.

Never is planning a bigger headache than it is when we design software to control large computer electronic systems. It's very hard to design a system along with its software. They depend on each other. They must grow together. Yet they're created by quite different people.

Trouble starts when the government writes contracts with software designers. We spell out just how the software will look, years in the future. That way, we expect to get just what we pay for, with no padding or fudging.

We call that the waterfall model, because work cascades down from one stage to the next. The pieces are supposed to mesh with the certainty of gravity. Of course they never do. With tedious regularity, we get bad software, cost overruns, and both.

The problem arises in the very nature of planning. Good planning has to see the process, not just the end. It has to include means for changing itself as the work unfolds. It has to anticipate its own failures along the way.

Terrible trouble has followed software contracts around. We had to shut down five nuclear reactors in 1979. Their design software had been flawed. The Therac-25 radiation therapy system killed five patients with overdoses in the mid-'80s. The Hubble Space Telescope was plagued with software problems. So were the defensive electronics on the B1 bomber.

An alarmed congressional committee has pointed the finger at procurement thinking. I've worked under such contracts. I've had to fill out countless timelines in proposals. By April I'll design the apparatus. I'll build it by July. I'll collect the data by Thanksgiving and analyze them during Epiphany. Just try doing original work that way!

No sensible parent makes his child absolutely accountable. The result would be an absolutely irresponsible child. Procurement people are slow to see that. They forget process in the rush to guarantee results.

Good design is an interaction among responsible people. The trick is to rough something out -- then interact and correct. Software has to evolve with hardware. We must spiral in on a good design, says Science magazine writer Mitchell Waldrop. You cannot specify anything good and new before you create it.

Big over-specified systems are too hard to fix when they break down. Our procurement system itself is like bad software. Maybe it should be replaced. We need a system that will attract designers who want to be responsible -- not just accountable.

I'm John Lienhard, at the University of Houston, where we're interested in the way inventive minds work.

(Theme music)

Waldrop, M.M., Congress Finds Bugs in the Software. Science, Vol. 246, 10 Nov., 1989, pg. 753.