Projects: Failure and mounting a “scratch monkey”


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.


4 thoughts on “Projects: Failure and mounting a “scratch monkey”

  1. Peter says:

    Here’s a link to someone who claims to have spoken with the author of the device driver.

    BTW, the monkey and VAX were was in the Dept. of Medicine.


  2. The Veg says:

    I hope that someday living beings (people of different races, gender, etc., and non-human animals) are no longer exploited as being simple objects to be used by another.
    “Steve, don’t forget to order some more capacitors, red and green LEDs, and a couple of monkeys, get young ones, they put up less of a fight, when you order parts again. Oh, and get me a roll of solder also.”

    On a more positive note, I do like the idea of articles that show us that failure can be a healthy aspect of innovation.

Comments are closed.

Discuss this article with the rest of the community on our Discord server!

Gareth Branwyn is a freelance writer and the former Editorial Director of Maker Media. He is the author or editor of over a dozen books on technology, DIY, and geek culture. He is currently a contributor to Boing Boing, Wink Books, and Wink Fun. His free weekly-ish maker tips newsletter can be found at

View more articles by Gareth Branwyn


Maker Faire Bay Area 2023 - Mare Island, CA

Escape to an island of imagination + innovation as Maker Faire Bay Area returns for its 15th iteration!

Buy Tickets today! SAVE 15% and lock-in your preferred date(s).