Pages

Tuesday, August 18, 2009

It's a Dirty Hack, But Someone Has to Do It

I had finished a fairly complicated application -- to the client's specification -- that featured a complex system for selecting advertisers for various types of announcements. Although the money was paid, the project lay dormant for many months until the client started selling the ad spots.

Unfortunately, the person selling the spots had been left in the dark on how the system was built and sold the ads in a way that was completely contrary to the current tools -- control panel, automation, and front-end were now incompatible.

I looked at every way possible to make it work within the capabilities of the application but there was no reconciling the way the product was sold and the way the product was built.

To make matters worse, the deadline for the "new" way of doing things was two weeks and I had already had a full plate. I sensed stupid hours in my future, but promised the client I would come up with something.

The more I got in to the code, the more I realized that it was worse than I anticipated. I tried several approaches, but everything was backward in terms of implementation and data that was previously needed in one place was now needed somewhere else -- some where the scope was completely wrong.

I really only had a weekend to work out a solution and the "real" way of doing it would probably take a week's worth of work.

Sometimes you just have to hack something in place. In this case, I bypassed all of the dynamic stuff and just hacked in the raw data for the specific advertiser. Yes, lots of really complicated and fascinating code was essentially discarded for a plain text band-aide that will have to be fixed some day. It wasn't pretty but it was simpler, and more importantly it got the job done quicker.

Sometimes the greatest difficulty in this situation is getting over the fact that you are hacking otherwise excellent code into pieces.

This brings me to yet another truth in programming:

It's a Dirty Hack, But Someone Has to Do It.

You are the best candidate to hack on your own code and when the rubber hits the road, the reality is you just have to do it.

But what can you do to minimize the damage?

  1. Leave comments for yourself (or the next guy) wherever you need to change the code.
  2. Use @hack or some similar marker so you can easily find the changes and comments.
  3. Go back and fix it on a rainy day.

No comments:

Post a Comment