The World’s Leading Microsoft .NET Magazine
   
 
timstall

Donate Today!

Search Box

 

Calendar

««Sep 2008»»
SMTWTFS
 
1
2
3
456
78910111213
14151617181920
21222324252627
282930

My RSS Feeds








Mailing List

Most Popular Tags

                                                           

Dealing with pressure-hacks

posted Thursday, 10 August 2006

Life is tough, and sometimes that forces us to make tough decisions. For developers under time and money pressure, that means occasionally writing code hacks that you’re not proud of.

I’ve met some developers who think that the only reason that hacks exist is because other people are dumb. Certainly many hacks are caused by ignorance, but many are also caused by unrealistic time, money, or features constraints that pressure someone into writing bad code. The critics seem to think that if only the world were as smart as them, then all code would be perfect – just like theirs (sarcasm). Ironically, these critics never seems to have had to dealt with the pressure themselves – they can tell you how you’re supposed to do it, or how their last company (that’s 10 times bigger) did it, or what the “Best Practices” are, but they don’t actually implement it themselves.

The best way I can think of to handle pressure-imposed-hacks is to:

  1. Acknowledge that it is not ideal, and identify the problems.
  2. Ask if others have a better idea (that can be implemented under the same pressue).
  3. Document your hack, ideally in the source code or wherever else it matters.

The first step brings everyone to the same page. The second gets others’ feedback – maybe they know a helpful trick that will make everyone work. The third reaffirms to your fellow developers that while you’re aware that this isn’t ideal and you’re not trying to hide it, the code needs to be completed and this gets it done. These steps require humility and confidence from the coder: they admit what they don’t know something, but they can be confident that their approach at least solves the problem. Ultimately the company stays in business not by the critic who points fingers at everyone, but by the developer who makes the project work – even if it has an occasional hack.

Open question to readers - what do you think about hacks due to excessive pressure? Any interesting stories?

tags:  

links: digg this    technorati    




1. Philip Stevens left...
Friday, 11 August 2006 6:39 am

I agree, hacks can be necessary evils (at times). Microsoft seems to agree being that one of the default key words is HACK for the comments based task list; so when you say to document the hack, I agree, and that is the first part of my documentation, afterall admission is the first step in recovery.

I also try to make time to come back around to it and unhack whenever possible; usually this is done when the reason it is called a hack is found (when the user discovers the 2% of the cases that this implementation doesn't address). I suppose there can be other hacks that are fully functional... but off the top of my head I'm not thinking of any and would probably classify those (from my ivory tower of course) as bad code :)