Retrograde Dynamic Tablature Assembly

There are two different kinds of hacking. Of course, that’s a pretty general statement, and we can certainly divide the category of hacking into two parts many different ways (white hat vs black hat, hardware vs. software, etc), but the way in which I am speaking today is not a functional split. It is a split in environment in which the action is undertaken, rather than a difference in what task is actually performed. So far, I’m being pretty opaque, so let’s get to specifics.

I refer to hacking in probably something like the original sense of the term, which is doing something clever and resourceful with something that wasn’t intended for the purposes it has been put to by the hacker. This could mean infiltrating a remote computer using a buffer overflow attack, or writing new software for your iPod so it can play Doom. The key element here is constraint. The actions of the hacker are constrained in some way, and he must use intelligence and experience and whatever else is at his disposal to accomplish some goal despite those constraints. If my definition is allowed to be stretched, any work done around constraints can be viewed as hacking (For example, see the excellent Dinosaur Comics, in which the author uses the same image but different text each day to make something new).

If hacking is about constraints, how about we divide up hacking into two different types based on whether the constraints are self-imposed or imposed by some external agent. In the case of the hacker trying to gain access to a remote system he is not allowed into, the constraint is imposed by the admins of the remote system. They put into place security measures to prevent the hacker from gaining access, and if he wants to gain access he must twist around these constraints and find weaknesses that can be put to his use. In the case of the hardware hacker putting Doom on his iPod, the constraints are externally determined by the architecture of the device, but the choice of device is at the discretion of the hacker. While the hacker into a remote system may only be able to get what he wants from that specific server, if the hardware hacker decides it’s too hard to work on an iPod, he can do what he wants on some other device.

The far end of the self-constraint/external-constraint spectrum is the hacker who is not constrained externally at all. This is where we come to the crux of the “vs.” mentioned in the title. The hacker who places constraints on himself can be either lauded as a genius, or despised for implementing a terrible solution. The difference is the environment in which the “hack” is executed. If the hacker is on his own time and chooses constraints to make something challenging, and comes up with a solution that is unexpected, it doesn’t affect others. The pejorative “hack” comes when the hacker was simply too lazy to come up with a proper solution, and his only “constraint” was that he didn’t want to take the time to do something the “right way.”

So let’s focus the discussion on professional programmers who are employed for a purpose, or to open source programmers working with others toward a common goal. On the one hand, the externally constrained hacker is the one who the night before the expected launch of a program finds a massive bug that would require rewriting 40% of the code base to fix “the right way.” He implements a hack, and is a hero the next day. On the other hand is the programmer whose code is just one long string of hacks, completely unmaintainable and unreadable by anyone but the original hacker. This man is either dropped for incompetence, or kept on forever because he’s the only one who can maintain the code. Either way no one (save perhaps himself) likes what he’s done.

In the former example, we may raise issues with how the project was structured that such a major fundamental flaw was found only at the last minute, but in general most people would agree what the hacker did was right. There was no time available, the constraints were placed on him. In the latter case, it’s a safe bet everyone would blame the “hacker” who couldn’t be bothered to stop hacking. In both cases, the hacked code probably looks similarly incomprehensible, or may not scale, or may make the code base more fragile, but the circumstances are what decide whether these weaknesses are acceptable or not.

The good hacking of the first example can turn into the bad hacking of the second example if the architectural problems are not rectified. The time constraint of the first example evaporates at some point, and now you just have bad code sitting in there. There might be some other constraints (such as budget), but if the goal is quality, that hack done in the nick of time needs to be rectified. Here is the reason why: Hacking is a response, not a strategy. Hacking is a riposte, not an attack. If you are not backed into a corner, you shouldn’t be risking your life to get out.

If there is no constraint, you shouldn’t be hacking.