PRODUCING A HACK AT MIT - ENGINEERING IN ACTION by Eri Izawa
1992 and 1996
The Massachusetts Institute of Technology has a well-known reputation for its
exceptional students, who excel in everything from science and engineering to
hacking. Hacking in this sense has nothing to do with breaking into
computers (which is often called cracking at MIT); instead, it means to
produce a clever, benign, and amusing prank for the public to admire and
appreciate. Hacks range from the famous Campus Police cruiser on the Dome and
the MIT-labelled weather balloon in the 1982 Harvard-Yale game, to less
well-known pranks, like the giant sliderule in the Student Center atrium and the
Christmas lights that spelled out ``MIT'' in six-foot tall letters on the Little
Dome. Hacks have become a way of life at MIT; hardly a term goes by without
strange objects appearing in odd places.
But as common as hacks have become, they still require a great deal of
insight, hard work, and old-fashioned engineering. Although some hackers may not
fully realize it at the time, the production of a successful hack follows the
same creative and technical process as any large-scale engineering project -
with the added complication that, along with traditional issues such as cost,
safety, manageability, hackers must avoid getting caught by the Campus Police!
(Though many hacks happen in public places, some are set up on places such as
rooftops, which are not meant for public access.)
The first step of planning any hack is to decide upon the final product.
Often, this is the ``What if?'' thinking stage. The giant plexiglass sliderule
that appeared in the Student Center, for example, was a result of students who,
tired of the plans for an unpopular sculpture of a shaman's hat containing human
hair, decided to construct something more symbolic of MIT's ``nerd image,''
while providing an unobstructed view of the atrium. Hence, they decided to build
a sliderule made of transparent plexiglass. Of course, sometimes hackers just
decide that it's time to ``pull a hack'' for no particular reason at all.
Hacks must also pass a ``couth'' (the opposite of ``uncouth'') test to be
considered a true hack, as opposed to an obnoxious and worthless prank:
hacks must be amusing and generally benign. For example, any idea that may be
interpreted as racist would probably be discarded. The mailing of fake notices
of student loan cancellations, which resulted in hysterical phone calls to the
Bursar's Office, is a case where the perpetrators failed to apply the couth
test. In addition, hacks that cause permanent structural damage are avoided;
hackers believe that property damage is not only inappropriate but bad for
future hacks, since causing Institute repair costs could result in an
administrative backlash against hackers.
Once the general idea has been established and accepted, the design begins.
As with any engineering project, cost is an important initial factor. Funding
comes exclusively from hackers' pockets. Since many hackers tend to be
undergraduate students, as one anonymous hacker puts it, ``they also tend to be
poor.'' For a group of ten hackers, the cost of a hack rarely exceeds $100, or
$10 per person, and ``anything above about $8-10 [per person] would require the
hack to be something really astonishing,'' says the hacker. To reduce costs,
some hackers forage in trash bins and scrap piles for building materials.
[ Top ]
Time is also a valued student commodity. Although something as simple as a
banner may require over 100 man-hours to make, individual hackers hope to spend
no more than 10 or 20 hours on construction; most students cannot afford to
spend more than a few hours per week. Consequently, larger hacks often require
the involvement of many students to spread out the workload, and some hacks may
take months to complete. As with any project involving a large number of people,
this necessitates careful management, coordination, and planning. Luckily for
the hacking process, many students tend to be willing to spend an entire night
devoted to deploying a hack, probably because it is far more exciting than
construction.
Conscientious hackers, like good engineers, are also concerned about hack
safety. It's likely that a hacker's worst nightmare is seeing a hack fall off a
rooftop; aside from the embarrassment, bystanders may be injured. To prevent
safety and structural problems, many hacks are deliberately ``overbuilt.'' For
example, one hacker says, ``the slide rule (35 lbs of plexiglass) was held up by
eight 300-lb test ropes, each individually tied.'' Outdoor hacks require special
protection against the elements, especially the wind. Banners are made of cloth,
because paper banners have been known rip in strong winds. Wind also increases
the strain on ropes by turning anything with an exposed surface into a sail;
hence, the Christmas lights hack had a volleyball net substrate, which has
minimal wind resistance, in addition to being tied down with weighted ropes and
duct tape. Still, unforeseen conditions can ruin a hack: an effort to change the
color tiles on the Media Lab building ended prematurely when sunlight warped the
painted wooden replacement tiles so much that they fell off; luckily, the tiles
were at ground level and posed no safety hazard.
Unlike most engineering projects, hackers have the added worry of trying to
make sure they don't get stopped by non-hackers during the final installation.
In engineering terms, this simply means that there are tighter than usual
constraints on portability and the rapid assembly process. Although a hack may
soak up over 100 man hours to build, it ideally should only take a few minutes
to put into place, or ``deploy'' (in hacker jargon). Hackers are willing
(although only grudgingly so) to wait hours for the perfect deployment moment -
when no witnesses are present - but they aren't willing to spend hours
installing a hack where they can be spotted. The more exposed the area, or the
higher the traffic through the area, the more practice and planning is required.
This also means that a hack should be transportable, so that the hackers can
quickly bring it out of storage to its intended destination at a moment's notice
(ideal conditions tend to be short-lived). Extremely large hacks, such as the
Campus Police cruiser and the two-story screw that graced the Great Dome, must
be built modularly, so that the parts can fit through doors and reach the
deployment area. Banners or large nets with objects attached are rolled or
folded up.
[ Top ]
The need for rapid deployment also means that a hack must have only a few,
simple, readily-accessible attachments, which can quickly and securely fasten it
to the wall, ceiling, or rooftop. Having too many attachments is confusing,
time-consuming, and tends to involve lots of ropes that get easily tangled.
Anything more complicated than simple clamps, ropes, weights, and knots are
avoided as well, for similar reasons. The time-honored ``KISS'' (Keep It Simple
Stupid) engineering principle aptly applies. Of course, a large hack supported
from only a few places needs special attention to structural stability.
A final design factor conscientious hackers consider is removability. Good
hacks should be removable without causing structural damage, or ideally, any
damage at all. In fact, most hackers prefer to take down their own hacks,
partially to retrieve equipment before it gets confiscated, and partially
because they feel that they are most qualified to take their hacks down safely.
Hence, means of attaching hacks to a surface are usually limited to
non-permanent techniques. This is generally complimentary with rapid-deploy
techniques, which stress the use of knots and weights instead of time-consuming
welding torches or drilling equipment. One example of the importance of
removability is the die hack, in which a cloth with dots (like those found on
dice) was placed without official permission over an officially permitted large
cubic structure hanging in Lobby 7. The hackers later helped both MIT Physical
Plant and the creators of the cube take down the fabric safely and easily.
Apparently, the hackers were inspired to help when they learned that the plan to
remove the hack would have made the fabric even harder to remove than before.
The speedy removal was especially important because the cube was to be displayed
as part of an important meeting between an MIT research group and Japanese
representatives!
Once the design has been finalized, construction begins. Luckily for MIT
hackers, finding and using construction equipment is rarely a problem. Although
most hackers shy away from projects that would require thesis-level complexity,
many of them are competent with and have access to power tools, sewing machines,
electronics, and shop equipment. Other construction necessities, such as paint
and duct tape, are even easier to acquire and use. One of the worst construction
issues is space, since hacks tend to be large. ``This wouldn't be so bad, except
hackers also usually don't want people to know there's a hack under
construction,'' notes an anonymous hacker. Most large hacks end up spread out in
living group hallways, empty classrooms, or even unused subbasements.
Once constructed, hackers try to make sure that all the parts of the hack are
tested - to make sure the Christmas lights actually light, to see that banners
won't sag, or to make sure tape will stick to the wall. As any good engineer
knows, the failure to test something may mean finding flaws the hard way - for
example, more than one unfortunate group has found that pulling something up the
side of a building with a rope doesn't work, because the concrete edge of a roof
will cut through even thick rope. Also, the hackers need to test their own
skills: knot-tying, climbing, and other deployment necessities. Though hackers
would love to rehearse the deployment at least once, generally they cannot risk
practicing at the actual site, and must make do with off-site practices and
verbal descriptions of what is to happen.
After design, construction, and testing, a hack is ready to be deployed. With
luck, all goes as planned. An example of a successful, fast deployment is the
attempt to change the tile colors on the Media Lab. From the all-clear starting
signal, to the placing of ladders and fake wooden tiles on the wall, to the
removal of the last ladder, was a mere three minutes. Another successful
deployment took longer: the Christmas lights hack took over 20 minutes, time
mostly spent making sure that a pile of cardboard boxes painted as presents were
safely glued to each other. According to one hacker, the problem was that they
``hadn't taken into account the fact that glues tend to dry more slowly in cold
weather.'' Still, 20 minutes wasn't too bad, because, as another hacker says,
``rooftops are relatively low-visibility areas.'' Of course, the Christmas
lights weren't turned on until the hackers were ready to leave.
Assuming the arrival of Campus Police hasn't halted the deployment
prematurely, the hackers do final checks on their hack, and then slip away,
leaving MIT - and sometimes the rest of the world - to marvel at their
handiwork. Perhaps only fellow hackers, however, can truly appreciate the
effort, ingenuity, and planning that has gone into the design, construction, and
implementation of the best hacks. It is engineering in action.
This article first appeared in "Is This The Way to Baker
House?" A Compendium of MIT Hacking Lore, published by the MIT
Museum, 1996.
[ Top ]
|