Hacker vs Professional

Even with the luxury of highly detailed specifications there arise moments where the developer has to make choices about how to implement a feature. The decisions made during these moments provide a pretty good indication of whether or not the developer is of the hacker variety or of the professional variety.

Let me provide, in lieu of a formal definition of a hacker, a few examples that illustrate the hacker mindset.

The user needs a way to enter a password with the text masked as it's entered. The framework you're using, e.g., Windows Forms, doesn't have a built in way to do this. How do you go about meeting this need?

The Hacker's instincts will involve one or more of the following steps:
  • Using the debugger to identify the internal structure of the textbox.
  • Using Reflector to decompile the framework and reverse engineer its logic.
  • Using Spy++ (or ManagedSpy) to reverse engineer the communication patterns.
  • Hooking directly into the underlying API on which the framework is based and, using the knowledge acquired in the previous steps, finding a way to intercept keystrokes then replace their display with asterisks.

The Hacker may not settle on this approach but those are his instincts. To him there is an inestimable joy in unraveling the framework, peeling back its layers, identifying what its inventors overlooked and plugging into the framework in a clever way likely not envisioned by its creators. The fact that its creators apparently didn't think of this obviously important feature is evidence of their mere mortality. And since the Hacker is also a mere mortal, he's got as much reason as anyone to fix the shortcomings in the framework. He might even get a little kick out of subverting the confines of the framework.

The Professional is also a mere mortal and like other mortals also has instincts. His instincts will typically involve one or more of the following:

  • Using the framework's documentation to identify any events exposed by the framework that can be used.
  • Mining the samples that ship with the framework for examples of solutions to similar or related problems.
  • Mining the guidance/overviews that ship with the framework for ways to plug-in and/or extend the textbox.
  • Lobby for an alternative solution (e.g., a popup that quickly disappears) that can be built with stock components included in the framework.

The Professional, like the Hacker, may also end up settling on a different solution but his instincts are radically different than the Hacker's instincts. To him the framework, shortcomings and all, represents a genuinely better way to do things. He remembers the bad old days of MFC and the worse old days of Win32 and doesn't miss the oodles of lines of plumbing necessary just to perform tasks the framework allows him to do without writing a single line of code. He'll go "hack into" the framework if he absolutely has to but would much rather find a way to do things the "framework" way.

The Hacker and the Professional have a lot in common. They're both writing software. They'll often use many of the same tools (e.g., debuggers, profilers, tracers, IDEs, etc...) but their instincts will drive them to use them at different times and in different ways. The Professional will tend to think of the debugger as a way to identify what's wrong with his own code. The Hacker will tend to think of the debugger as a way to figure out what the framework is doing "under the hood"; a way to find the secret spot that he can use to plug-in and do things the way he thinks they should have been done in the first place.

Say what you will about Hackers a few things are, in my experience, pretty universal to them:

  • They're very smart. Sometimes they're even geniuses.
  • They like to write code.
  • They have a strong sense of curiosity.

The big problem with the Hacker is that he tends to write code that is very difficult to maintain. Because the knowledge the Hacker gains by reverse engineering is usually very incomplete, often in ways germane to the way he intends to solve the problem, his solutions are plagued by seemingly inexplicable errors. His solutions work well 90% of the time then, for no known reason, crash or hang the other 10%. He might have been able to piece together what was going on "under the hood" at the time he was looking but is usually not able to reverse engineer all of the assumptions in effect.

Over time, the Hacker's hacks accumulate. He forgets the insight he had while stepping through the decompiled framework method. The next version of the framework changes whatever internal peculiarity allowed his hack to work causing it to stop working long after anyone even remembers the hack. As these hacks accumulate they start to impact the rate and quality of development. The rate slows down because making changes requires accommodating hacks that must first be deciphered. The quality goes down because the accumulated hacks interfere with each other.

Given this indictment of the Hacker, does the Professional do things any better? I'll cover that angle in the next "Hacker vs Professional" post.

No comments:

Post a Comment