Papers by M. Mitchell Waldrop
Science, 1985
The faint companion of van Biesbroeck 8 is the first known "brown dwarf"-a cosmic ember not quite... more The faint companion of van Biesbroeck 8 is the first known "brown dwarf"-a cosmic ember not quite massive enough to ignite Somehow, it seems wrong to call the thing a "planet." It is an enormous ball of hydrogen and helium with roughly the same composition as a star. At 1400 K it is hot enough to glow like an ember. It has several dozen times the mass of Jupiter, which is by far the largest planet in our own solar system. In fact, it is not much less massive than the body it orbits: its parent star, van Biesbroeck 8, lying about 21 light years from Earth in the constellation Ophiuchus, is one of
Science, 1991
bb Tendrils and knots. A close-up of the glowing gas in Orion.
Science, 1987
a founder ofGenetics Institute, says the technology to clone TPA was "common knowledge."
Science, 1985
Le modele standard de quasar admet un corollaire: de nombreuses galaxies proches, parmi lesquelle... more Le modele standard de quasar admet un corollaire: de nombreuses galaxies proches, parmi lesquelles peut-etre meme la Voie Lactee, sont des quasars morts qui abritent encore des trous noirs ultra massifs
Science, 1989
Dig into any of the government's chronically over-budget and behind-schedule development programs... more Dig into any of the government's chronically over-budget and behind-schedule development programs-the Hubble Space Telescope or the B 1-B Bomber, for example-and you'll find that a good fraction of what gets labeled as "waste, fraud, and abuse" actually stems from crummy software. Not only do the development agencies habitually spend millions of dollars on operations software that is buggy, inadequate, and late, they then have to spend millions of dollars more to fix it. So says a just released report* from the House Science, Space, and Technology Committee's Subcommittee on Investigations and Oversight. Written by subcommittee staffer James Paul, who spent 2 years working on it, the report also names a culprit: the government itself. "Government policies on everything from budgeting to intellectual property rights have congealed over time in a manner almost perfectly designed to thwart the development of quality software," it says. Paul's brief, but strongly worded report echoes the complaints that computer scien-How not to do tists have been muttering for years. "The Space Telescope wa [federal government's] procurement process mare. is as much or more to blame for poor software as any other single thing," says Peter Freeman of George Mason University, who just finished up a stint as head of the computer research division at the National Science Foundation. "There are huge numbers of people involved [in the agencies] who fundamentally don't have the knowledge or experience to make good decisions with respect to procurements." The report says that reform must begin on the conceptual level, because purchasers still regard software as an afterthought. Project managers, agency heads, and congressmen alike tend to focus on sexy hardware such as radars, airframes, and engines, assuming that the software to control all this gadgetry can be taken care of later. Yet that assumption can be costly. In 1979, the Nuclear Regulatory Commission shut down five nuclear reactors for upgrading; a software flaw in the computer-aided system used to design them had left them vulnerable to earthquake damage. In the mid-1980s, a Canadian-built radiation therapy machine, the Therac-25, killed at least four people when a software error irradiated patients with massive overdoses. "Software," says the report, "is now the choke point in large systems." On the other hand, it will be difficult to make the software development process more flexible because the federal procurement system effectively demands that contractors write the software using bad methodology. "Out on the technical frontiers," the report says, "the government requires a legally binding contract specifying in excruciating detail exactly how the system will look at delivery some years hence." The tacit assumption is that programmers will then use these specifications to write, test, and debug the software. In the programming community this approach is known as the waterfall model because the work *"Bugs in the system: Problems in federal government computer software development and regulation" (Subcommittee on Investigations and Oversight of the
Uploads
Papers by M. Mitchell Waldrop