When the concept of doing a Projects: Failure something came up years ago, originally as the idea for a Make: Books (in case you hadn’t realized, “Projects: Failure” is a silly twist on our “Make: Projects” book series brand), we were talking about how it could be story-driven, people sharing spectacular failures and what they learned from them. I blurted out: “Oh, like mounting a scratch monkey!” Everyone looked at me like I’d forgotten to take my meds (again). But I’ve never stopped associating this idea with the scratch monkey. I’ve brought it up several times since we’ve launched this series online, and each time, people tilt their heads sideways like a dog hearing a high-pitched noise. So, here’s the scratch monkey story.
The term “scratch monkey,” or the adage “always mount a scratch monkey,” comes from a tragic, allegedly actual, incident that took place 1979/1980, at the University of Toronto. It became a cautionary tale that floated through early netspace, especially USENET newsgroups, and a number of different versions emerged. It became part of the hacker lexicon, part of the venerable Jargon File, and then part of the resulting Hacker’s Dictionary. Here’s an excerpt of the entry from The New Hacker’s Dictionary (3rd Edition):
As in “Before testing or reconfiguring, always mount a scratch monkey,” a proverb used to advise caution when dealing with irreplaceable data or devices. Used to refer to any scratch volume hooked to a computer during any risky operation as a replacement for some precious resource or data that might otherwise get trashed.
This term preserves the memory of Mabel, the Swimming Wonder Monkey, star of a biological research program at the University of Toronto. Mabel was not (so the legend goes) your ordinary monkey; the university had spent years teaching her how to swim, breathing through a regulator, in order to study the effects of different gas mixtures on her physiology. Mabel suffered an untimely demise one day when a DEC field circus engineer troubleshooting a crash on the program’s VAX inadvertently interfered with some custom hardware that was wired to Mabel.
There’s definitely a key lesson in there about projects that fail and what one can learn from them: never commit resources to a project you can’t afford to lose if something goes wrong and to test your project first in ways that won’t destroy it (or key components) if something goes awry. How many times have you (have I) committed that last crucial part or piece of material, or whatever, to a build and then had it get ruined? So, when in doubt, if you can: always mount a scratch monkey!
BTW: The version told in the Jargon File/New Hacker’s Dictionary claims it came directly from the sysadmin involved in the incident. But the AFU and Urban Legends site questions this. Here’s part of their entry:
Current University of Toronto sysadmins have expressed skepticism. For one thing, in almost all versions of the story, including the ostensibly documented one in the Jargon File, the computer is a VAX; at the time a VAX would have been a very unusual platform for this kind of data acquisition (they used PDP-11s). The Toronto zoology department has never been licensed to work with primates; the only section of the university that could have done experiments of this nature was the School of Medicine. Investigation continues
.
Let’s hope it isn’t true, no monkeys were harmed in the making of this cautionary tale, and you can still benefit from the moral of the story either way.
Here’s the rest of the Jargon File entry.
Here’s the Wikipedia page with some links to some of the variations on the story.
More:
ADVERTISEMENT
