The Art of The Hack

June 14th, 2008 @   - 

In this article, I’ll discuss a skill that should be part of any serious developer’s tool kit: the ability to hack.

What’s a hack?
When used as a noun, a hack describes a piece of software code that is known to be sub-par. It violates basic software engineering concepts such as lack of abstraction, lack of encapsulation or plain old bad design. It can even breach a contract within its own ecosystem of classes. Nevertheless, it does the job, fills a hole, or solves a problem in a quick yet inelegant way. To hack is simply the act of producing a sub-par piece of software. Merriam-Webster’s definition is less kind: “to cut or sever with repeated irregular or unskillful blows”. I disagree and take exception to the part about being unskillful. When it comes to developing software, knowing when and how to hack is a skill that separates top tier developers from the rest.

If you are fortunate enough to earn a living creating software that is used in a commercially successful way, you will inevitably face unique challenges with respect to software evolution. The key words here are “commercially successful”. With commercial success comes change: new features, new ideas, good ideas, bad ideas, optimizations, refactorings and re-designs. All this change over time takes its toll by corroding the code base. Add tight project deadlines, last minute requirement changes, and surprise bugs discovered during testing and you have the perfect environment to put your hacking skills to good use.

The ethical dilemma
If you are serious about software development, hacking may put you in an ethical bind: do you compromise your integrity to produce a hack? What about the ensuing guilt? And worse, how will your peers judge you when they come across your hack living in the code base?

Broken pipes and scotch tape
Before I address these issues, let me take a step back to make an analogy. If you’re awoken to the sound of water gushing into your basement from a broken pipe, your first thought is to hack together a solution and to patch the pipe with scotch tape. (I can tell you from a recent experience that this won’t work but let’s stick with this analogy anyway.) Software works in much the same way. If you are working on a production problem that causes core dumps, solution elegance is an afterthought. This is when your hacking talents can shine. Of course, hacking in emergency situations is standard practice. Hacking also has its place in prototyping or creating proof-of-concept designs. But what about other grey areas: can hacking be a design choice?

Hack by design
When you are evolving a code base over the span of several years, you begin to see software as a living, breathing (and sometimes smelly) thing. With change being the only constant, software code moves along the maturity continuum. It evolves from prototype to naïve to sophisticated and robust implementation. It can also regress or progress back and forth along the continuum as new features force successive modifications and refactorings. These can be seen as internal factors. In parallel, software code also marches to the beat of external factors such as project timelines, testing cycles and multiple versions living in different parts of source control manager. Put together, these internal and external factors create environments that dictate how problems that appear in the code should be solved. In some environments, a clean solution should be adopted while in many others, a hack is the way to go.

Hacking also has its place when you begin to realize that your code structure no longer meets your current needs. You don’t always have the luxury of investing in a massive re-structuring or refactoring for several reasons. You may not know where the requirements are headed in the long term. You may not have fully grasped the problem or most likely, you are not given the time nor the support from stakeholders to properly address the problem. These are all grey-zone examples where there is a problem in need of fixing but no middle-of-the-night type emergency. I believe that these are legitimate reasons to opt for hack by design. The hack may be temporary or can even end up sticking around for years. It will only impede maintenance if a) it doesn’t really fix the problem or b) more changes are required in the same area. In these cases, a hack will do more harm than good. Another important pre-condition is the geographical containment of the hack. It should be self-contained within one component. If you are creating lots of sub-par code and spreading the dirt around in a wide area, then it’s no longer a hack – it’s really just a bad idea with no upside. However, if you can solve the problem with a hack and close the box, there is a strong argument in favour of hack by design. It can be addressed with a clean solution when the circumstances are favorable.

You won’t find this sort of advice in any “best-practice” publication as it borders on the unorthodox. I’m certainly not advocating hacking as a career choice since you surely won’t rise to greatness if you overindulge in the fine art of hacking. But the occasional, irregular and skillful blow to a nasty bug will certainly catch the eye of your manager. You’ll be appreciated for solving a problem quickly. And since managers usually don’t write code, they won’t see the ugliness and will therefore not even perceive a downside. Like a fine wine, all good things in moderation.

Comments are closed.