The Atlantic has an interesting article on the issues surrounding influenza vaccinations. Makes a pretty good case that the flu shots don't have much effectiveness in keeping people from dying. There's a rebuttal out, of course.

The scariest part for me is the poor quality of the data on flu deaths. Diagnoses are based on symptoms, not tests of the virus, so we don't actually know how many people have been getting sick or dying from influenza. No one's doing well designed experiments to test the effectiveness of the vaccine and one of the big arguments (herd immunity) would be damned hard to test in any case.

I suspect we're not going to have a real grasp of the effectiveness of medical treatments until we give up on the privacy of medical records. If we get to the point where everyone's records are searchable, and detailed to the point where you can tell if a swab test was H1N1 positive or the doc just wrote a prescription to make the patient go away, there's going to be a lot of patterns discovered that'll make irrelevant all the watch-36-patients-for-six-months microstudies that policies get based on now.

One of the minor flurries in Washington DC right now is a line item in the defense budget an alternate engine for the F-35. Not something I'd care that much about if I wasn't working on that plane. The idea is that having a second company making engines for the plane will provide a back-up against problems and cost savings from competition. Given that both the current and previous administrations have tried to kill that piece of the program it's not that widely held an idea. The case against it is pretty simple--why pay for two designs and production lines when you only need one to get the job done?

So various op-eds are appearing extolling the virtues of competition and offering the historical precedent of the competing F-16 engines. Yes, both companies would have a better incentive to improve on cost and quality as they vie for each year's batch of engines. But everybody offering that argument seems to be just fine with the engines going into a single fighter design produced by one partnership. If competition is such a great thing wouldn't more of it be better? In the absence of those arguments it feels like a typical effort to defense Congressional pork barreling.

I'm not even hoping for someone to question whether it's a good idea for a single plane to replace the F-15, F-16, F-117, F/A-18, A-10, and AV-8.

I needed a configuration change for my account on our main database. After a few calls they decided that I wasn't asking for this because I'm too lazy to search on narrow criteria but actually need need to do large pulls like I said. So I got a call telling me that they were emailing the instructions but "it's a long, drawn out process" and feel free to call if I need more help. I felt pretty wary about that--I was expecting "get your manager to fill out form A and then get the Vice President for IT to fill out form B" and such.

Then I get the instructions. Pull file X out of the database. Put in this directory. Doubleclick (it's a .bat). Log off and back on. Done in a couple of minutes.

I shudder to think what kind of users the tech support folks have had to deal with if they're describing that as "long and drawn out."

Bill Whittle celebrated the Apollo XI anniversary by dropping politics for a bit and visiting XCOR Aerospace to look at their rocket-powered aircraft. Part One of the video looks at XCOR's success in converting conventional aircraft to fly under rocket power. Part Two looks at their Lynx suborbital design. I'm a serious fan of XCOR. I'd met Jeff Greason before he started doing professional rocketry and got a chance to present to his crew in Mojave once. They're taking the best approach to developing new technology--incremental steps, getting a working system they can test and operate at each step. The next step is a custom-built vehicle that'll actually exit the atmosphere. I'm looking forward to seeing it fly.

Moore's Law of Mad Scientists* continues apace.



* "Every 18 months, the IQ required to destroy the world drops by 1 point"

The Chair Force Engineer does a great job of summing up my attitude problem at work:

The morale of engineers is directly tied to the work they are given by their management. If you want to keep engineers happy, give them tasks that are worthy of their efforts. When management fails to do that, they have nobody to blame for poor morale but themselves.

He's planning on moving on to non-technical non-government work. I wish him luck. Hopefully he'll discover there's some places in the world where engineers have work worth doing.

The New York Times discovered that the nation's best engineers are avoiding government projects. Well, sure. I'd be doing commercial work if I had applicable skills. Alas, I've been in the government tarpit for so long I suspect I may never get out.

The article covers the reasons for avoiding government projects on the individual level but completely misses the top-level causes. Yes, projects take too long, waste lots of time, and fall behind the state of the art. But saying "bad management" just begs the question of why with so many successes in the past things keep getting worse (note that the article focuses on military projects, but the problems apply to all big government development efforts).

Most government projects--and all the big ones--aren't about building something. They're about giving Congressmen pork to bring home, giving the bureaucracy something to process, and keeping companies in business. The actual mission is merely a pretext. It has to be a good pretext to bring in votes from Congressmen not getting slices of the pork but it's still just a pretext. The bring-in-votes goal leads to pretexts that sound good rather than actually being useful for the people down in the mud (or wherever the users hang out).

Once funding is approved and the whole thing starts to slide downhill the top priority is ensuring that the butts of all managers associated with it are completely covered. So anyone who might complain gets to add their requirements to the list. Committees are formed to diffuse responsibility for the specs and architecture. Any delay or confusing rewrite is preferable to getting caught in a mistake. Bids get protested and redone until the lawyers can't come up with any more excuses to quibble. Finally a contract is awarded.

And then some poor, sorry SOB gets the responsibility for building the thing. The requirements are the wish list of everyone who could fit at the table. The budget is what Congress was willing to carve out of the other pork projects. The deployment schedule was set to the earliest possible date after the retirements of the proposal team leaders. The engineers who did the preliminary designs are all chasing other contracts. So with limited resources the new project manager has to create a team from scratch and teach them what they're supposed to make.

With all those constraints on him the PM's only real decision authority is over the order that the stakeholders will get fucked over. Congress goes to the end of that list, of course. Piss them off and the program's gone. The bureaucrats, users, and anyone else Congress will listen to go to second-to-last. First on the fuck-over list? Why, his engineering team trying to build the thing, of course. It's not like he can realistically pick anyone else.

Can this happen to commercial projects? Sure it has. If the back story of Windows Vista ever comes out it might look a lot like that with the appropriate names changed. But commercial projects always have one very sharp constraint--someone outside the company has to be willing to give money for this product as a user, advertiser, or whatever. If the customers stop buying the company goes bankrupt. If a government contractor produces a horrible product the troops get issued it anyway . . . or have to keep duct taping the old ones together even if that costs more than replacing them.

If the government completely redid its procurement system it would probably get better results. The engineers working on the projects would certainly be happier. McCain's battery prize proposal could be a step in that direction. But the current system is just going to keep accumulating more sludge in the arteries and smart young engineers will be staying the hell away.

Three years ago Pyramid published a gaming article I wrote, The Hills Are Alive With the Sound of Panic. It was mostly an excuse to explore the Hysteria Department at Illuminati University, but the plot focused on the invention of a "Fear Projector." I wanted an appropriate mad science gadget to drive innocent bystanders into a panic. Naturally there had to be a bit of technobabble describing how this thing worked:

The students used a combination of strobe lights and ultrasonic
vibration to make a working cannon-sized beamer
One of the problems with writing science fiction--even when you're doing mad science--is that it's hard to stay ahead of the curve. Turns out there is a government contract for just that kind of gadget:

Military funded researchers are preparing to test a nonlethal weapon that combines light and sound. Nicholas C. Nicholas, chief scientist of Penn State's Applied Research Laboratory, told an audience yesterday at a nonlethal weapons conference that in the first half of next year, the lab plans to test DSLAD, the Distributed Sound and Light Array Debilitator. It'll use essentially off the shelf technology to see if combining aversive noises with light produce some special debiliating effects.

I think "Fear Projector" still has a better ring to it than "DSLAD", but they probably couldn't get any good names through their review committee.

Not, amazingly, a meme, though maybe I should turn it into a quiz.

montedavis challenges all space cadets to confess Which X-Treme Spacer Are you?

I clearly fall into "Free-Fall Enterprise" and "Skunk Wonks" except I've done too much math to hold to the former and have too many responsibilities (>0) to be the latter.

Aubrey de Grey's Ending Aging is a fascinating book. It's not light--I took two Heyer breaks while I was wading through it--but I think it's a very important work. In fact, if I had friends who were in medical research, or undergrads interested in biology, I'd be buying them copies right now. This interview is a good introduction to de Grey and his quest to end aging. In short, he thinks we can stop aging, reverse at least some of it, and have healthy, vigorous lives for centuries. The book gets into the how.

De Grey (and his assistant, Michael Rae) do a damn good job of explaining the intricacies of the metabolic problems behind aging. His proposal is to find ways to fix the damage done over time without bothering explore all of its sources or the precise ways they can lead to death. This, and his other heresies, have made him unpopular among many scientists. He's taking an engineering approach, just wanting results without explanations of everything else in the tangle. He goes through the seven areas in detail. The evidence he lays out includes failed experiments as well as successes, it's not a propaganda piece.

Much of the discussion is on the legal and political issues in aging research. You can't get a grant from the NIH to study aging because it's not officially a disease. For the same reason the FDA won't let you test a drug solely for fighting aging. Fortunately for de Grey's plans there are diseases which are similar to the aging mechanisms, or subsets of them which are recognized as disease. For example, Alzheimer's is a subset of the general problem of junk proteins and other material accumulating on the outside of cells.

Once the various techniques are developed we can be treated to eliminate aging damage, and prevent some of the future damage. There's no guarantee that his proposals will work and he admits it. But the benefits are enough to justify placing some long-odds bets. This conflicts with the cautious attitudes of medical researchers and causes some of the hostility to de Grey (and I could see him being ostracized for his proposed cancer cure alone). The damage doesn't have to be fixed all at once. Give someone an extra ten years and at his next rejuvenation appointment there'll be ten more years of progress to apply. That can get us to "escape velocity", where our lifespans get extended one year every year.

Getting there is going to be tough. Right now the research is still at the level of animal experiments and there's not much funding. The Methuselah Mouse Prize is being offered for researchers who increase the lifespan of mice, funded by private donations. De Grey hopes a breakthrough in rejuvenating mice will create popular support for government funding of aging research. I'd settle for eliminating the government restrictions which prevent some of the research that could be done now. And I'm thinking about how much money I'm going to put into the Mouse Prize myself.

My former employer made the news again, this time for a good reason. They've announced a new design of their tourist rocketplane. This is three designs past where it was when I left. I helped produce this concept:



That was the first stage of a cargo launcher. The grey compartment in the middle opened to release a satellite and upper stage before reentering. This was right when Iridium was going bankrupt and the market for LEO commsats went *poof*. So I went back to my old job and the rest of the company converted it into a tourist vehicle. When the new guard took over they announced a new design based on a Learjet fuselage. That's out in the latest one, they're doing a from scratch structure, and I'm not at all surprised. Their design does have a few features that intrigue me.



The first bit that catches my eye is the canards (fins by the nose) and T-tail. The old crew had worked under the assumption that flat pieces smaller than the wings couldn't handle reentry. Looks like all that wind-tunnel testing says differently.

The jet engines are now afterburning and the rocket is ignited at 40,000 feet. They say this increases total thrust-to-weight by 50% so I suspect they increased the ignition altitude so they could use a larger nozzle without flow separation issues. The engine is a modification of an Atlas vernier, which is braver than the old design. We'd worked to the rule that any engine development would go over schedule so we only designed to off-the-shelf parts.

Another big concern for us was making sure the jet engines wouldn't have to endure the heat of reentry. The easiest way to tell the difference between design iterations was to check the location of the engine inlet, which always had a solid door blocking it during reentry. But the new team says they "Don't need to protect inlets during reentry". If the engines can handle the maximum reentry heat and pressure I'm impressed. Though it may be that they've positioned the engines in the lee of the wings so the reentry loads will be reduced to what they can handle.

The article says the trajectory would be "nearly vertical" which surprises me quite a bit. I can't help wondering if the reporter got it wrong. Wings can give you a good boost on the way up by counteracting gravity, but you need to have a relatively shallow trajectory to get the best use of them (it's a complicated optimization problem). I'd gone round on this once with a professor who'd done an analysis of the launch vehicle concepts out there and (in my opinion unfairly) ranked assisted-horizontal-take-off very low. Turned out he was constraining the first stage to be vertical at 2nd stage separation and that hurt performance. The 2nd stage benefited from all the horizontal velocity the rocketplane had as orbital velocity needs to be horizontal anyway. Then again, that's not an issue for tourists. What a vertical trajectory does for tourists is maximize the peak Gs on reentry. That's acceptable if the peak isn't too high.

I'll be watching Rocketplane as they build this design and I wish them the best of luck.

Kent Sepkowitz is a doctor I like. He's actually willing to admit more people have been saved from disease by ditchdiggers than by doctors.. What he's worried about is deaths from bacterial contamination of food, and I agree that trying to make the food supply utterly safe is impractical. Well, at least impractical for most people. The "pick two" for food seems to be "cheap, safe, tasty" and there's not many people willing to subsist totally on MREs or blow half their income on food. So Sepkowitz advocates dosing people with just enough pathogens to train their immune systems to deal with the inevitable contamination they'll have to deal with.

Rather than frantically throwing money at new ways to eradicate the pathogens that reside in shit, we should fund the boring scientists who focus on untangling the intricacies of the gut's immune system. Labs, answer this: How much shit can we safely eat and, as importantly, how much must we eat to remain healthy?

What I love about this is that a doctor is looking at the vaccination question from the other side, trying to establish minimum and maximum total amounts for the immune system insults. It's a wonderful change from the folks who insist that vaccines are good, therefore more vaccines are better. A good next step would be performing their studies on statistically valid sample sizes. After that they can analyze the distribution of the reactions to see what fraction of the population would handle this badly and how to recognize them, instead of calculating a mean optimum dose and prescribing it for everyone.

Defective Yeti has invented a major improvement in CAPTCHA technology. Instead of reading the characters in an image to prove you're not a bot, you have to prove a little bit more . . . .

Lumus Co. expects to ship video eyeglasses in 2008. This is something I've been wanting for a while. It's a pair of eyeglasses projecting a video image equivalent to a 70" screen nine feet away. It's probably not up to supporting true augmented reality but it's a major step toward it. They're also putting some serious work into the aesthetics of the device as a way to obtain popular acceptance. It's nice to see that in a tech start-up.

Rarely has this icon been more appropriate.

celticdragonfly wants me to share the conversation we had over lunch yesterday. I mentioned something about global warming uncertainties and she complained about the arrogance of people who think humans can precisely control the planet:

celticdragonfly: "Why not just change the orbit while you're at it? You can move the planet away from the Sun and cool it off that way."
selenite: Pause for thought. "Hmmm . . . find a big asteroid in an eccentric orbit and give it a kick at aphelion. Make it do a fly-by of the Earth and it'll perturb the orbit. That'd be the best leverage."
celticdragonfly: "Kick it how?"
selenite: "If you give me the combined nuclear arsenals of the planet, no problem."
celticdragonfly: "Oh, great, light off a rocket under them, that'll be safe." Sees my expression. "No, you're going to use Orion, aren't you?"
selenite: "If I've already got the nukes, why not?"
celticdragonfly: "Nuclear winter, that'll stop global warming."
selenite: "Hey! Orion is clean. It's much less polluting than using them for a war. Most of nuclear winter is the smoke from burning cities. Now if you want a nuclear winter, use the nukes to set off a volcano."
celticdragonfly: "One right next to some peaceful aboriginal people? Oh, that'll go over really well."
selenite: "Well, Mount Rainier would take out Seattle . . . or there's the Yellowstone Caldera. That'd give you a chance to relieve pressure and maybe save the whole continent from a disaster."
celticdragonfly: "I'd like to see you tell an environmentalist that you're going to solve global warming by setting off a nuke in Yellowstone."

Popular Mechanics has an essay by Stephen Flynn on infrastructure problems in America. All true. We've got more disasters coming, I'm afraid. The trick is going to be making it easier for state legislators to get re-elected by funding maintenance instead of sponsoring nifty new projects.

Three employees of Scaled Composites killed in rocket engine test.

Rocketry is an unforgiving business. I still remember the shocked look of a classmate when I explained nitroglycerine wasn't energetic enough to be a useful fuel. But giving the human race the ability to escape this one fragile planet is a cause worth sacrificing for.

A couple of the books I've read recently illustrated the powers and dangers of nanotechnology. One of the disputes in the field is whether molecular manufacturing can provide exponential production capabilities. MM would let us create a "nanofactory", a machine which builds things atom by atom, capable of producing anything it has the design data for. Exponential production happens when a nanofactory can build a duplicate of itself. Then the they could both duplicate themselves, until we have 4, 8, 16, 32, . . . enough nanofactories for every household in the world to have one. That would totally eliminate the world economy as we know it. If there's no limits on what the nanofactories can produce there could be a wave of homemade WMDs that would eliminate the world as we know it.

The Diamond Age: "Feed" Nanofactories

One of the boxes was called the MC. It was built into the wall over the counter. Nell dragged a chair and climbed up to watch as Harv worked at it. The front of the MC was a mediatron, which meant anything that had pictures moving around on it, or sound coming out of it, or both. As Harv poked it with his fingers and spoke to it, little moving pictures danced around. . . . Harv gave it an especially dramatic poke, and then a new mediaglyphic came up, a white circle with a narrow green wedge at the top. The wedge got wider and wider. The MC played a little tune that meant you were supposed to wait. Harv went to the fridge and got himself a juice box and one for Nell too. He looked at the MC disdainfully. "This takes so long, it's ridiculous. . . . We've got a cheap Feed, just a few grams per second. Pathetic." . . . . Finally the music came to a bouncy conclusion just as the white wedge vanished. Harv . . . poked a mediaglyph that was an animated picture of a door swinging open. The MC took to hissing loudly. "Got to release the vacuum" he explained. The sound ended, and the door popped open. Inside the MC, folded up neatly, was Nell's new mattress.

This is a world where even the poorest homes have a nanofactory. There are even public ones free to passerby. Those "matter compilers" have a sharply restricted list of products they'll make. Even if someone hacks the user interface to program one to produce something else he can be blocked by central control. Each nanofactory is hooked up to the "Feed"—a physical line that delivers power and prepared materials. The nanofactory can only work with specially purified streams of individual elements (probably bound into carrier molecules). If an unusual combination of elements is requested the Feed will refuse to deliver them and probably sound an alarm.

As befits the social structure of the book's Neo-Victorians, nanofactories can be given increasing flexibility for higher-class users. An Equity Lord can presumably build anything he has a design for. In that environment production is limited by the availability of designs. So intellectual property dominates the economy (entertainment having an apparently larger share than product designs). New nanofactories can only be created with the permission of the Feed owner and have to be connected to a Feed before they can produce.

A nanofactory can be "off the grid" if it has dedicated infrastructure. A converter is needed to transform raw materials into the purified elements accepted by the nanofactory. If there's no regular power available it has to have a generator of its own. Depending on the robustness of the technology cooling and vibration isolation facilities may also be needed.

Exponential production stops when it runs out of any one of the ingredients needed to produce another duplicate. If the nanofactory can't build a piece of its infrastructure new ones are useless once the existing infrastructure is fully used. New infrastructure can be installed until the nanofactories are processing the available inflows of feed materials and generator fuel. The limit may be the number of people available to set up newly produced nanofactories. That wouldn't stop production but limit it to N per day instead of being exponential. If robotics technology has advanced enough the factories could produce installation and resource extraction robots to keep exponential growth going until the available resources are exhausted.

By this stage "exponential" production is moving so slowly that any interested party can interfere. Visiting a macrotech factory will show you that infrastructure facilities routinely outmass the actual material-processing tools. For a nanofactory to usefully reproduce itself it's going to spend much longer on the infrastructure than on the new nanofactory. Adding robots to the list would make each cycle take even longer. The neighbors will have plenty of time to notice Dr. X transforming his backyard into an industrial complex.

The Diamond Age: "Seed" Manufacturing

Instead of an army of stonemasons and carpenters, the builder was a single man, a portly gray-bearded fellow puffing at a long slender pipe, carrying a leather bag on his belt. Arriving at the center of the building site, he reached into his bag and drew out a great seed the size of an apple and pitched it into the soil. By the time this man had walked back to the spiral road, a tall shaft of gleaming crystal had arisen from the soil and grown far above their heads, gleaming in the sunlight, and branched out like a tree. By the time Princess Nell lost sight of it around the corner, the builder was puffing contentedly and looking at a crystalline vault that nearly covered the lot.

A "Seed" is a self-contained device for creating a single product from raw materials. It's a miniaturized version of the exponentially reproducing nanofactory above. The seed starts with some "assemblers"—nanoscale robots which move around the outside of the product, precisely placing atoms to build the whole thing (a nanofactory can be considered a set of immobile assemblers). The first few assemblers concentrate on making more assemblers until there's enough to build the whole product. Then they all switch tasks and rapidly assemble the product. Once the job is done the assemblers self-destruct, leaving it ready for use.

Like a plant, the seed assemblers have to get their resources from the surrounding soil. There might be a separate set of "gatherer" robots to collect materials and energy, or the assemblers might do it themselves. Carbon would be the most-needed element—most nanotech designs rely on crystalline carbon for their structure (hence the book title). It will still need small amounts of other elements. Making a nanodevice function requires some variations in the size and bonding characteristics of the atoms used to let the parts have the shape and movement needed. This assembler has to find enough of each element to finish its duplicate.

For example, look at a design for a nanoscale gear:

This uses hydrogen, carbon, silicon, nitrogen, phosphorus, oxygen, and sulfur. Running short of any one of those elements keeps the assembler from finishing the gear. Other elements are needed less often, probably in a power-law distribution. As more assemblers are built they'll have to go farther and farther from the seed's location to get the material they need. But until picotechnology is invented the assembler will have to keep searching until it finds the exact atoms it needs.

Energy will also be collected (in the form of organic molecules worth burning) from the soil. Solar power can supplement that but is too diffuse for the rapid production visualized for the seeds.

This concept could be fine for producing a house or car from Iowa topsoil. If you drop that same seed into the Arizona desert the assemblers will crawl out and find . . . lots of silicon dioxide. Very little hydrogen, less carbon, and no energy sources worth mentioning. The assemblers will wander about a bit on solar power, but you won't get a house.

My backyard splits the difference. Under the thin topsoil is red clay. So a seed could build something small, but would run out of energy before finishing a house. If I wanted to grow a car in my backyard I could help the seed by putting down "fertilizer"—molecules rich in energy and needed elements. A bag of charcoal would do nicely. But the more fertilizer I have to put down the less sense it makes to use a seed instead of running a Feed to the site, or making the car at a nanofactory elsewhere and bringing it home.

In the novel Dr. X wanted the Seed technology to bring back the Confucian ideal of a society based on peasant labor. Rather than his people being welfare clients dependent on the output of a distant Feed source, he saw a new peasantry fulfilling everyone's needs by planting seeds. That's not going to involve enough harsh manual labor to induce the virtues extolled by urban poets, even after planting peanuts to restore depleted fields. The Seeds would keep the people safe from single-point feed failures and domination by foreign feed sources.

The Neo-Victorians and their Common Economic Protocol allies opposed developing the Seed because it would let WMDs be made with no intervention from the feed source. But that requires a WMD Seed. Nanofactories are general-purpose tools with a user interface for inputting designs. Any restriction on inputs can be hacked around with time. The Feed has to be constrained to keep nanofactories from building WMDs or other forbidden goods.

A Seed has no user interface. You take it out of the packet, drop it in the ground, and step back. It produces whatever it was programmed to. If the Seed's original creator wanted a decentralized society new Seeds can be part of the product. A house seed can grow a house with a drawer full of new seed packets for cars, clothes, food, toys, etc. If it doesn't make new seeds people have to go to a central source every time they need something, which is just as centrally controlled as the Feed.

Creating a new kind of Seed is harder than creating a new design for a nanofactory to produce. The designer ("Alchemist" in the book) has to create the plan for obtaining raw materials and assembling the product. The design has to be optimized for the soil the seed will be grown in (what mix of elements and energy sources it has).

Anyone with the capabilities of an Alchemist can make a WMD seed. One of these is the nightmare of the Neo-Victorians. A seed can be carried into their secure inner areas without being detected as a dangerous object. Then it could be planted and launch a WMD attack. The only way to stop it would be to detect the seed assembly process and smash it before the WMD is ready, a task roughly as difficult as keeping every dandelion from reaching puffballhood in an entire county, forever.

There's two ways to deal with the threat of WMD seeds. One is ubiquitous surveillance (and sousveillance) as detailed in Brin's Transparent Society. If everyone's being watched terrorists can be caught in the act before doing much harm. Abandoning privacy would destroy many social structures, so it would be a traumatic transition. The alternative is to be very careful with who can become an Alchemist.

Walter Jon Williams called them "Aristoi" in his novel. These geniuses were carefully tested for technical ability and psychological stability. Once they passed the tests they would receive full privileges to use nanotech. These constraints weren't as concerned about using nanotech for WMDs as much as the danger of technical errors creating out-of-control nanotech devices—the "gray goo" problem.

Gray Goo, or Flesh Eating Assemblers

Sanjay was a hollowed-out asteroid, an irregular potato shape set in orbit by a strap-on gravity generator. Another chill ran through Gabriel as he saw that it was covered with what looked to be like dirty-white foam. Slow-motion bubbles rose to the surface, burst, left brief hollows soon filled by more glittering nano. Occasionally there was a scintillation, shining six-sided reflective patterns that formed for only a second in sunlight, like a diffraction halo that formed around a dust speck sitting on a camera lens.
IR scanners showed that the surface was hot. The nano was still active, still working away on something. . . . The Eldest Brother deployed a solar shield, several kilometers wide, between Sanjay and the sun, just in case the nano was absorbing energy from photons. IR readings showed the surface temperature had decreased immediately.
Pan had slowed the stuff down.
[snip other countermeasures]
After the nano had all been destroyed there was precious little left of the asteroid, a little stone spine, elongated and fragile, like a squab bone etched by acid.
From Aristoi by Walter Jon Williams

Gray goo is what happens when a seed goes bad. Instead of assemblers duplicating themselves until they hit the number needed to build the product, they keep duplicating forever. It was named by Erik Drexler: Though masses of uncontrolled replicators need not be gray or gooey, the term "gray goo" emphasizes that replicators able to obliterate life might be less inspiring than a single species of crabgrass.

Some excitable reporters have read descriptions of gray goo and penned lurid scenarios of a puddle of goo converting the whole Earth to assemblers in a matter of days. Exponential growth can work that fast—if it doesn't run into any limits.

Look at that gray puddle out in the woods. Say it's 10 kg of goo and an assembler can duplicate itself in a minute. How much goo will there be a minute from now? Not 20 kg. Only the assemblers on the outside of the puddle have access to new materials and energy. The inside of the puddle is filled with junk: molecules with atoms more common than needed, assemblers inert until they get more energy, others sitting with a replica half finished, waiting on more material. If assemblers could teleport to a virgin field after each replication they could keep growing exponentially.

The gray goo will keep growing but at a rate proportional to the surface area of the puddle in contact with useful raw materials. The goo would expand through the woods until it reached an area lacking carbon or energy. A concrete road or sandy desert would stop it. An assembler optimized for building in forest will have a carbon-based structure. A solid piece of silicon dioxide won't provide anything useful for next generation of assemblers. The same problem hits goo headed straight down. Once it's through the topsoil it'll be short on materials and energy. Bedrock will stop it cold.

All this makes gray goo a slow-acting, easy to contain menace. On a small scale it's like a bacterial infection, where spreading bits of it to a new location is a bigger worry than the initial outbreak. Large gray goo infestations can be dealt with like forest fires. Creating a "backfire" to strip key materials from the path of the outbreak will create a barrier.

A gray goo assembler doesn't have to be carbon-hungry. It could be designed to primarily use silicon or another suitable element. Even if a gray goo assembler is optimized for a particular environment, such as the asteroid above, it may not be able to propagate. Solid rock doesn't have consumable energy for the assemblers. They could work off of solar power but that's diffuse and only available to the surface of the puddle. The goo might be able to eat an asteroid, but it would be slow, small nibbles, not huge gulps.

In the example above of gray goo destroying an asteroid, the author is violating conservation of energy to produce a dramatic scene. The nanobots are effectively boiling away a chunk of solid rock, but they're getting their energy from the sun. If there was enough sunlight to support vaporizing the rock that asteroid would have been destroyed long before the nanobots arrived. They can't supplement solar power with chemical energy because it's stone, which is not burnable—it's the ash of silicon burned in oxygen. Even if the asteroid was a chrondite, made of burnable carbon, there wouldn't be any oxygen for the nanobots to burn it with. So gray goo can't boil away asteroids, not matter how dramatic a scene it makes in the novel.

In honor of Pixel-Stained Techno-Peasant Wretch Day, I'm showing some engineering work I did for free. This isn't anything I'd actually get paid for, at least not in this decade (or possibly century) but it does show how an engineer can analyze a practical problem.

Back in July, pauldrye wrote a Pyramid article about an alternate history setting for GURPS Infinite Worlds. One colorful detail he included was a space elevator anchored at the equatorial island of Batam.

Fanboys being what they are, someone immediately took offense at this skyhook not being precisely on the equator and claimed it would wind up oscillating north and south. I pointed out the flaws in his logic and it got heated. This is when I wound up flaming someone for dissing centrifugal force. Eventually it was clear I'd have to run the numbers to end the back and forth.
( Cut for lots of equations and a big diagram )

Aerospace and software engineering have many tales of huge projects that ate incredible amounts of resources and then failed, sometimes completely, sometimes producing something with a fraction of the capability originally desired. There's a ton of case studies on them, sometimes whole books of them. These get blamed on forcing the technology beyond achievable limits, requirements creep, poor management, lack of resources, etc. I think all of those come down to one problem—too many requirements.

The requirements I'm talking about here are:

1. Top level. They describe what the system must do, not just a part of it. A complicated vehicle can have many, many derived requirements allocating the top level ones to each subsystem, but the derived ones aren't part of this discussion.

2. Top priority. Any requirement that can be sacrificed to meet another one isn't really a requirement, it's a goal, something optional. Of course, how the requirement is designated officially may not match that definition. If a "goal" has to be met or the project loses funding, then it's really a requirement and equal to all the other "top" priority ones.

3. Not just technical. Any constraints on the schedule or budget for a project count as requirements. If the project has to stay under $1.5M/yr, deliver the production version for $3000 each, and be shipping by 6/1/2009, that's three more requirements. Other constraints count too—if a specific development methodology or tool set must be used, that's a requirement. So is a security regime imposed on the project staff (classified, ITAR, proprietary—they all complicate things).

4. Not just formal. The informal requirements on a project can be the most difficult ones. US government projects are infamous for these . . . despite thousands of pages of requirement studies, the design can be driven by an "understanding" that work will be done in a particular Congressional district, or the employment level at a NASA facility will not be cut.

The more requirements there are on a system the more likely it is that two or more of them will directly conflict. Ideally such conflicts will be recognized before the project gets go-ahead, but there are projects that never resolve those conflicts and instead will thrash about trying to square the circle without realizing (or admitting) what the problem is. But fixing them isn't enough to assure success.

Even if all the conflicts are carefully ironed out of the top-level requirements the project's chance of success will depend on the number of requirements:



Every requirement added reduces the chance of success.

Everone accepts that you can't get everything you want. Lots of engineers have a sign saying "Cheap, Fast, Good: Pick Two" in their cubicles. But even if you "pick two" you haven't capped the number of requirements for your system.

Technical performance—"good"—can go in many directions. The more different tasks the system has to do the less the designers can focus on any one of them. In practice each task gets assigned to a different design team, with the project management and/or systems engineers trying to make sure they don't interfere with each other's performance.

Let's look at an example: the often longed-for flying car. Even if you don't set any limits on the cost or schedule, there's going to be a lot of requirements describing what you want it to do: Speed X in the air. Speed Y on the ground. Road handling characteristics. What kind of fuel it takes. Cargo capacity. How many passengers and how much room they get. Essentially you'll be adding the requirements for a Cessna 150 to those of a Mazda Miata, with only a small percentage being eliminated in the overlap.

Doubling the number of requirements doesn't just double the complexity of your design. When you design a part to meet a particular requirements, you have to look at its effect on every other requirement on the system. The number of interactions increases roughly with the square of the total number of requirements [I = (x^2 - x)/2 ].

In the flying car example, look at what the air bag designer has to deal with. For a car it has to meet NHTSA safety requirements, interface with the car's electrical system, and not interfere with the steering wheel's function (various other requirements such as acceleration and range aren't affected but still have to be checked to make sure). Adding the requirements for a flying forces changes to the design to comply with FAA regulations, keep the airbag from going off during a rough landing, and make it lower weight to support flying performance.

Some requirements don't directly conflict but push the design in different directions. Take the flying car's wheels. Improving the traction and responsiveness on roads requires wider tires and heavier brakes and suspension. For better performance in the air the tires need to be narrow (to reduce drag) and all components must be low weight. In situations like this the performance allocations to the subsystems must be made carefully to ensure both requirements can be met.

Since engineers tend to advocate for their favorite requirements, allocations and flow-down to lower-level requirements can be contentious. The more top level requirements pull in different directions, the harder it is to find an acceptable compromise. The compromise may be vague wording that postpones the conflict to the next level of detail.

With conflicting agendas among the different development teams, each protecting their pet requirements, engineers have to take time away from their own tasks to check up on other teams. It's easy for someone to make a change to his design that impacts another team's performance. Avoiding that requires studying the whole project's requirements, annoying supervisors who want their tasks done on time. Frequently Team B won't realize they've been affected by Team A's change until after it's been approved and incorporated into the baseline. This can produce thrashing—A's change forces B to redesign their subsystem, causing a problem for C. If C's proposed fix affects A's subsystem the cycle will repeat until the system-level management recognizes the problem and imposes a common solution (or the system is delivered with flaws intact). This can be averted by each team reviewing proposed changes before they're approved—as required by every project's CM process—but analyzing piles of change requests is always a low priority task, discarded when the team is behind schedule.

This illustrates what the most precious resource of a project is:

The attention of the workers

If the engineers try to pay attention to too many requirements, they won't be able to focus on creating their designs. So they pick the ones that matter the most to them and ignore the rest. This is where process and security requirements do their damage. Time spent on learning new change forms, adding required markings to drawings, or evaluating data to see if it's classified or ITAR-restricted takes away from designing. Hiring more people can help with the technical workload but adding them for process/security enforcement just adds interruptions without reducing anyone's workload.

Concentrating attention is how the Apollo Program succeeded at its incredibly difficult task. "Man, Moon, decade" was a requirements set that everyone could grasp and apply to the problem in front of them. With a common goal and priorities engineers could trust each other and focus on their own jobs. Apollo proves even a very large project can be at the top of the success curve.

Projects at the bottom of the curve fail in multiple directions. Time spent arguing priorities or struggling with new processes causes schedule delays. The salary hours used add to the cost overruns. Thrashing from repeated changes drives up both. Technical performance suffers because no part of the design gets the attention needed to optimize total system performance. Worse, a conflict between requirements or subsystem designs could be missed, producing a product that doesn't meet the original need. Actual flying cars have been built but suffer from these requirement conflicts. Their performance is inferior to cars and light planes while costing more than the combined cost of both. Flying car makers have repeatedly gone bankrupt while nearly all Cessna owners also have a car.

When managers realize their projects are in trouble they start climbing the success curve. Cost and schedule requirements fall off the list once they've been passed but the design choices that gave up performance for low cost or quick manufacturing are still part of the design. Process requirements are frequently removed informally by paying lip service while bypassing the process steps. Deleting a performance requirement can be essential for getting back on track but can threaten the viability of the project. Removing a feature drives away the customers who wanted that capability. Government projects have their funding cut as stakeholders lose interest. If that doesn't leave enough money to meet the remaining requirements the project can go into a "death spiral".

A system can be built with a huge number of requirements if you go about it the right way—get a basic version working and only then add the advanced features. The C-130 Hercules cargo plane has been expanded to land on skis, fly into hurricanes, refuel other planes, infiltrate hostile territory, and be a platform for radio stations and artillery pieces. Developing all of those capabilities at once would have pulled the engineers in so many different directions they may not have delivered a working system at all.

In the software world this is called Spiral Development. The define requirements-design-build-test process is repeated several times, adding more requirements on each loop. The cycles continue until all requirements are implemented or the project runs out of time or money (This works in other industries. The author used it on an aerospace project.) Introducing a new development process should be done as a "zero" iteration, practicing the new methods on a "build one to throw away" prototype.

Not every project can be a spiral development. Some requirement sets can't be split into useful packages. More resistance comes from corporate (and government) cultures which believe a "Great Leap Forward" is faster and cheaper. They can still succeed if they don't let their requirements list get too long. Deciding on spiral vs. waterfall development is the job of project managers and chief engineers but all developers can push back on a new requirement. The success curve can be a useful tool for making it clear that someone's "tiny little new feature" can have an out of proportion effect on the whole project.

Too many requirements can kill a project.

Kill them first.