HK = [ Faqs ] [ Archive ] [ Community ] [ Map ] [ Search ] [ Link ] = HK
[ Newsletter ] [ MailingList ] [ Blog ] [ Updates ] [ News ]
     
 
Torna al Hac-K-Menu

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 ]

Released By DaMe`
Visits [1459460]