Dennis Shasha is a professor of computer science at the Courant Institute of New York University. He currently works with biologists on experimental design and network inference, with entrepreneurs on database outsourcing and on safe banking processes in the third world, and with finance folks on algorithms for time series prediction. You can find some of his Dr. Ecco's Omniheurist Corner puzzles at DrDobbs.com.
Cathy Lazere is a freelance writer. A former editor at the Economist Intelligence Unit, she has written extensively about corporate finance and technology.
This article is based on a section from the authors' latest book Natural Computing: DNA, Quantum Bits, and the Future of Smart Machines published by W.W. Norton in May 2010. Besides exploring the themes in this article in much greater depth (and in a biographical style), the book discusses even more extreme frontiers -- computing with bacteria, viruses, DNA, and even Jello. Their earlier book, Out of Their Minds: The Lives and Discoveries of 15 Great Computer Scientists, concerns the lives and work of the pioneers of computer science.
Reams of design documentation.
Legalistic specifications in incomprehensible specification languages.
Endless overly large meetings.
Most good programmers will run the other way. They want the freedom to create new functionality and make that work. But when they design software for safety-critical applications, say in aerospace or power generation, most will grit their teeth and do what they have to. After all, they look at mechanical engineers and the micron tolerances they can achieve. Clearly, the future belongs to the careful, to the precise, to the thorough.
Clearly. Except that this is probably wrong.
Designing high quality software for a controlled surgical environment or a well-studied automotive setting may not work at all for space, finance, or even large terrestrial engineering projects. When you are designing for what Jet Propulsion Laboratory engineers call "unknown unknowns," a committee's reams of documentation may leave millions of scenarios unexamined.
Is there some alternative? Yes, look in the mirror. Whenever you repair the wiring in an old house, ski down a wooded trail in imperfect conditions, climb a boulder for the first time, or cook a meal with the ingredients you happen to find in your refrigerator, you don't search your memory for a worked-out procedure. You adapt. It's as if some designer (intelligent/evolution -- we don't care) gave you hands, feet, and rudimentary senses and told you "go figure it out". Software for applications on the frontier of computing follows a similar paradigm: minimal human design, maximal adaptability. Let us demonstrate that to you.
Reactor Design: Compromise Without Prejudice
During World War II, a secret city arose in the hills of Tennessee. Oak Ridge National Laboratory started as part of the Manhattan Project with a mandate to produce and purify plutonium for the atomic bomb. Since then, the laboratory has diversified into energy, systems biology, and materials science research. Lou Qualls, a senior researcher and nuclear engineer at Oak Ridge, describes himself as a systems integrator. He puts different subcomponents together in order to realize complicated engineering designs for nuclear reactor systems. He uses genetic algorithms to propose designs. His approach is of the classic Holland-style [Adaptation in Natural and Artificial Systems by John Holland]:
- Start with a population of candidate designs, each consisting of choices about individual components that can vary in expense, weight, and performance.
- Evaluate each one to give a "fitness" score, perhaps based on the total system's monetary cost.
- Create a new population by selecting the fittest candidate designs and changing some of their components individually or by combining different designs together. (Always hold onto the best design to date in case you come up with nothing better.)
So, for example, one design might call for an expensive shielding material and a certain fuel whereas another might make do with a cheap shielding material and a second fuel. Combining them would associate the expensive shielding material and the second fuel, potentially arriving at a synergistic design that lowers cooling costs.
Qualls has used these designs, because they are better than what he has been able to come up with himself. He sees several reasons for this. First, unlike human designers, the genetic algorithm is willing to try designs very different from previous ones it has tried. The algorithm has no loyalty to history. If you doubt that humans preserve their biases as constraints when technology changes, just remember how many years passed in the early 1900s before cars no longer looked like "horseless carriages." Consider also that many recent business and technological innovations -- express mail, microprocessors, and the Web -- arose from people outside of the establishment who found better ways to perform existing services. The establishment was stuck in its initial design frame of mind.
Before he began using genetic algorithms, Qualls would take three weeks to come up with a preliminary design "and I made everybody real mad at me because nobody got what they wanted." But when a genetic algorithm churns out hundreds of designs, the specialists begin to see a pattern of compromises. People's attitudes improve. "The algorithm helps different subsystem experts understand the constraints of others," says Qualls. As a result, there's more cooperation among team members.
Qualls recalls trying to design a container for a spacecraft that also had to shield the spacecraft against gamma rays. The question was where to put the shielding material and nobody had a good idea. There were millions of ways to make layers out of different materials. "The genetic algorithm said that putting the gamma shield in a thin layer in the middle yields the cheapest and lightest-weight solution," says Qualls. The shielding expert confirmed that this design could work. The genetic algorithm had discovered the solution by exploring thousands of generations of designs in only a few minutes, saving time and money.
Whereas Qualls's team arrives at a tightly specified design, the method of finding those designs is entirely adaptive. Each choice of material or shape has a cost and a benefit. The genetic algorithm finds hundreds of good designs. Adaptation comes nearly for free: When the cost or benefit of a component changes, Qualls enters it, and reruns the genetic algorithm. No tears and no prejudice.
Most recent comment
Did Toyota study Bhopal?
Comment by IASCamp Mar 26, 2010, 03:42 AM EDT
The stories I have read lead to "the smell" that the cause of the accelerations is the series of decisions over time that leave "corner cases" where critical parts of the software do not execute.
The first "corner case" was the long accelerator pedal that did not let sloppy floor mats slide under the pedal.
If the management culture allowed that, what did they allow in the software after going to drive-by-wire cars? (Bhopal was a series of desisions that ignored standard best-practice chemical-industry safety concerns -- ___)
Glenn Reeves is very clear about critical parts of the software not executing in 'What really happened on Mars?'. He also covered the importance of embedded diagnostic tools for finding out what was going on when the software hung.
So the very-short, limited coverage, proprietary EFD that Toyota has used are part of the problem.