Nick Maiorano is an independent consultant with 20 years of experience as a software developer and architect. He specializes in building high performance server-side applications in Java as well as providing technical leadership. He has worked in the telecom, financial and aerospace industries and also co-founded a web-based start-up. Nick is a DZone MVB and is not an employee of DZone and has posted 8 posts at DZone. View Full User Profile

The Art of the Hack

07.21.2008
| 5252 views |
  • submit to reddit
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 (see post when good code goes bad). 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 awaken 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 such 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 favourable.

Conclusion

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.

From http://deepheap.blogspot.com

 

 

Published at DZone with permission of Nick Maiorano, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jay Ceron replied on Tue, 2008/07/22 - 7:15am

Hacking is a fact of life.  You can't always properly refactor or redesign to fix a bug or solve a production issue.  I think you can balance the guilt of doing this with proper code comments and FIXME or TODO statements so the hack gets addressed in the future.  And make sure it does!

Tranquiliser Gt replied on Tue, 2008/07/22 - 8:15am

I think a more realistic consequence is that most of 'TODO' or 'FIXME' things are not going to be fixed anyway.

Dhananjay Nene replied on Wed, 2008/07/23 - 2:34pm

Nice writeup.
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?

I think one way to help is to really think of how it impacts your customers and users. Will the hack help them get up and running quicker. Is there a way to introduce an hack and de-hack the code over the next few releases ?

The times you must *NOT* hack is when

(a) The code could be lesser secure

(b) You are sure it fixes the problem under consideration but are unclear whether or what problems it will introduce.

I believe that these are legitimate reasons to opt for hack by design.
If one is approaching the end of lifecycle software probably what you say may make sense. But if not, I believe you've overlooked highlighting some important considerations. Development teams will treat hacks as acceptable once they see the first hack coming in (especially if it is from a senior developer). Secondly the damage done by hacks is exponential ie. 2 hacks don't do twice the damage, they probably end up doing 4 (or some number based on the power of e) times the damage. How does one ensure that the first hack does not open up the floodgates for many more down the road.
And since managers usually don't write code, they won't see the ugliness and will therefore not even perceive a downside.
I was often the senior most manager and senior most developer who took the call. In general I encouraged the development team to let me know when a hack needed to be introduced. Many a times it is helpful to have management involved. 
It can be addressed with a clean solution when the circumstances are favourable.

For all the hacks I have implemented .. half of them might still be waiting for favourable circumstances.

Dhananjay

Steve Northover replied on Thu, 2008/07/24 - 7:41am

I'll go one step farther.  In my opinion, a successful code base contains at least 1% horrible hacks.  Not only are hacks a necessity of software life, sometimes attempts to clean up the 1% can lead to code bloat, extra complexity and performance issues.

For me, the most important thing is API.  If the implementation contains a hack that must be fixed in the future, is the API specified such that the hack can be removed?

Steve

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.