 Scientists have discovered a way to create an entire artificial respiratory system. That's amazing, but you have to admit that their apparatus looked a little bit cobbled together. Talk about hacking up a lung. This past December, video game developer Steve Gaynor gave everyone an amazing gift by asking his fellow programmers what crimes they committed while struggling to get their games to ship on time. The thread is a non-stop roller coaster of hilarious and sometimes horrifying confessions that show a little of how the sausage is made in video games and what sort of bizarre gymnastics are sometimes necessary to get these things to work. Every character, object, and bit of scenery in Wolverine's Revenge, including Wolverine himself, contains a variable with the sole purpose of indicating whether or not it's a helicopter lifting off. Instead of creating logic to handle the grammatical differences between singular and plural nouns, Seed Ship's random damage engine will always kill colonists in groups of two or more. Scooby-Doo, for the Game Boy Advance, would crash if you happened to collect one Scooby snack before a different one. So rather than figuring out what was causing the crash, one programmer wrote code to switch the two collectibles if a player got close to collecting them in the wrong order. Now, you might not be a programmer, but you can probably appreciate the particular flavor of these solutions. In classic computer parlance, they're hacks. Improvised, fiendishly clever, usually equal parts appalling and resplendent. The same flavor of problem solving can be found on the There I Fixed It and Redneck Engineering subreddits, a collection of duct tape and bailing wire bodges just barely hanging together, but still doing the thing they need to do. The primary factor that distinguishes a hack from other kinds of problem solving is an almost criminal vacuum of design. The careful, deliberate planning and architecture necessary not just to achieve some desired result, but to achieve it in the best way possible. In many ways, design is the opposite of hacking. It takes time, it's iterative, while hacks are the quickest and dirtiest answers that immediately spring to mind. Sometimes the fruits of that approach are brilliant, even heroic, but we probably share the sentiment that with enough time and resources, a solution that seems hacky leaves something to be desired. So why are designed solutions considered better? Better based on what criteria? It's not like thinking hard about an answer automatically makes it good. There's technically nothing that prevents you from sitting and pondering some problem for months and still ending up with a terrible answer. There's something that you're trying to work into the character of that answer. Some set of traits or attributes you're trying to grant by being thoughtful about what form it takes, rather than just piling on duct tape until it works. What is it exactly that we're trying to gain through the act of design that's better than a hack? Let's think a little bit about what sorts of complications you get with hacks. First and foremost, hacks tend to be fragile, a slight breeze and unexpected input, and all the complex machinery around the quick fix explodes in a catastrophic fashion. They can be inflexible, requiring just as much work to repair when the parameters of their operation change slightly, often more work than it would have taken to do it properly the first time. Because they're tailor made to patch one specific problem, they're not really reusable, can't be easily generalized to other contexts, and worse yet, reinforce whatever error or oversight led to their creation in the first place. If you ever want to fix the original problem, you can't just fix it. You also have to strip out the hack and fix everything that was attached to it. Okay, let's try flipping those traits on their heads to see if we can't identify some of the key benefits of design. Hacks are fragile, so good designs must be robust. They must accept suboptimal operating conditions with ease and keep chugging away even when other parts of the system have failed. The classic example of robustness in operation is the AK-47 assault rifle, a weapon which you can literally fill with pumpkin pie and continue firing without issue. Many designers, myself included, would roll our eyes if we were given that as a specification, but you've got to admire it when you see it. While hacks can be rigid, good designs are generally flexible and adaptable. Many real-world examples of hacky-type solutions can be ultimately attributed to a design that continues to work well in situations the creator never even imagined. Take this infamous Excel spreadsheet called arena.xlsn, a fully functional role-playing game built entirely in a tool intended for accountants and bookkeepers. The Excel programming team certainly didn't intend this usage of their software, but the design is so good that it can be abused this way without issue. Hacks tend to be single use and non-generalizable, so good design should probably be widely applicable and useful in many different contexts. The Microsoft Xbox controller was built for video games, but its ergonomics, interface, and easily adapted programming libraries have made it a useful tool for inspection robots, research labs, underwater drones. It's even used in the Navy to control submarine periscopes. It's a controller, and it turns out that it's very useful for controlling things because it's well designed. Similarly, as hacks can cause calcified dependencies on the bits and bobs they're attached to, good designs don't rely on anything in particular to continue working in a certain way to keep functioning as they should. For most 3D printers, a power failure means a print failure. If on our 99 of your 100 hour build, the lights flick off for a second, your printer will reboot, and you'll have to throw that giant lump of carefully sculpted plastic in the garbage and start over. The Prusa Mark III on the other hand, when it detects a power failure, will write its current location to memory so it can just start up again when the power comes back. Now I don't want this to come across as an indictment of hacking. Obviously, those who confessed their grievous game developer sins to Twitter knew they were doing something shady when they were doing it. They didn't need some pithy catchphrase and needlepoint over their monitors to remember how to code properly rather than slapping together something functional through brute force. Most were making the conscious decision that it was worth sacrificing all the benefits of good design to get something that worked quickly, using whatever spaghetti code was necessary to make it happen. Looking through the sometimes surreal creativity on display there, this obviously isn't the result of stupidity or lack of vision. It requires serious brilliance to enact some of these ridiculous clutches. And it's worth noting that, sometimes, through laws of probability, one may accidentally stumble onto a hack that turns out to be a solid solution, something that a team of designers couldn't improve on after years of careful thought. You might be surprised to learn that the vast majority of the entities in World of Warcraft, everything from turrets and traps to quest credits and cutscene triggers, is classified in the game engine as an invisible bunny. There are over 1,000 bunnies in the game's database, and only a handful are actual rabbits. Every other bunny on the list is invisibly performing some vital function in the game's world, quietly making every raid mechanic and boss fight work. That probably sounds like the most absurdly entrenched hack imaginable, but you might be more surprised to learn that it's a fairly common practice in video game development. In WoW, it's bunnies. In League of Legends, it's minions. In Fallout 3, it's NPCs with giant tram-shaped helmets. It turns out that characters are often one of the first programming categories created when making a game, and tend to have everything that a programmer needs to make something happen. Just about any variable or trigger or event can usually be handled by creating a character, making it invisible so it doesn't appear on the screen, then hanging whatever code you might need on that character, rather than creating a unique class for every little thing. It may sound crazy, but the invisible NPC method is fairly robust, flexible, generalizes to numerous types of games, and only really relies on one essential part of the game engine. What started off as a fairly hilarious hack is now a perfectly workable design solution. It's a fairly rare occurrence, but sometimes a really brilliant designer can look at something that's clearly hacked together and find good design in it. What's the most embarrassing clues that you've ever put together? Please leave a comment below and let me know what you think. Thank you very much for watching. Don't forget to ball the subscribe law share, and don't stop plunking.