March 2016
Volume 31 Number 3
[Editor's Note]
Chasing Fogbank
By Michael Desmond | March 2016
.jpg "Michael Desmond")
In 2000 the National Nuclear Security Administration (NNSA) embarked on a program to extend the life of select nuclear warheads—among them, the W76 model manufactured between 1978 and 1987. Used in Trident submarine launched ballistic missiles, the 100-kiloton warheads were among the most numerous in the U.S. stockpile.
A problem soon developed. Engineers working on the project found that an important component of the W76 bomb design—a classified material known as “Fogbank”—could not be manufactured. The facility that had produced Fogbank had been shuttered, and documentation about its manufacture was either lost or incomplete. Worse still, the staff that worked to create Fogbank in the 1980s was no longer with the government.
Dennis Ruddy, a general manager working on the refurbishment effort at the time, described Fogbank thusly: “The material is classified. Its composition is classified. Its use in the weapon is classified, and the process itself is classified.”
Fogbank may be an interstage material that helps trigger a fusion explosion by mediating the pulse of X-rays produced in the initial fission stage of a thermonuclear bomb. Regardless, the secrecy around it was a big part of the problem. Hobbled by institutional amnesia, parts of the U.S. nuclear refurbishment effort ground to a halt.
That left two solutions: Reverse engineer the manufacturing process from extant material, documents and facilities, or concoct a wholly new material to replace Fogbank. The government opted for both, throwing time, staff and money at the problem until it went away. Fogbank was eventually re-engineered. Despite years of delay and expenditures in the tens of millions of dollars, the W76 refurbishment program pushed forward.
Incidents like these provide a cautionary tale for software developers, who are often challenged to refurbish aging assets of their own. What happens in the software world when institutional memory falters? The global Y2K remediation effort at the turn of the century offered a glimpse, as aging Cobol and Fortran coders shuffled out of retirement to work on billions of lines of mostly forgotten code.
In fact, dangers arise whenever the work stops. Vital contextual knowledge about a software project begins to erode almost immediately, especially as team members disperse. Special “revival documentation” with system setup and configuration information can help address key gaps, but even a major investment in documentation can’t catch everything.
The Fogbank effort illustrated this. For months, engineers struggled to understand why the material they had reverse engineered wasn’t performing optimally. It was later learned that the modern cleaning processes used to purify component materials didn’t exist when Fogbank was first manufactured in the 1980s. In short, the end product they were producing was too pure. Only by adding specific impurities back into the process was the team finally able to fully reverse engineer Fogbank.
Have you faced your own Fogbank struggle? Let me know how you managed it. E-mail me at mmeditor@microsoft.com.
Michael Desmond is the Editor-in-Chief of MSDN Magazine.