Ayende @ Rahien

Refunds available at head office

Hack bombing

You have done it in the past, and you had little time and needed to get something working, so you put together something that made you cringe a bit. It worked, but it wasn't good. You maybe put a little TODO there, but deep in your hearth, you know that you are going to forget it. Let me introduce you to a new paradigm:

Hack bombing - the practice of where you leave a hack, you time bomb it so you would have to come back and fix it later.

try
{
   //do stuff
   return true;
}
catch // no idea how to prevent an exception here at the moment, this make it work for now...
{
  if (DateTime.Today > new DateTime(2007, 2, 7))
    throw new InvalidOperationException("fix me already!! no catching exceptions like this!");
  return false;
}

I wrote the above today. So it will work, for now... But in three days times KABOOM. My shameful secret will be revealed to the world, so I have to fix it before this happen.

Comments

Adi
02/05/2007 12:43 PM by
Adi

Sounds horrible to me:

http://dotmad.blogspot.com/2007/02/hack-bombing-is-horrible-idea.html

Pierre Henri
02/05/2007 06:27 PM by
Pierre Henri

lol :)

This one is quite funny.

Anyway, I'm sure that the end-user will Not like that, if it make it to production. And before that, the developer will keep changing the date ;)

JonR
02/06/2007 10:16 AM by
JonR

i like this idea. but what's to stop a lazy, degenerate developer like me just going into the code every few days and further pushing back the date?

Ayende Rahien
02/06/2007 10:29 AM by
Ayende Rahien

Absolutely nothing.

I am not even trying to force a lazy developer from doing this, I am trying to ensure that it doesn't get lost in the noise.

I should point out that pushing back the date every now and then is an act that you have to do consciously, so you are not losing this bug, you are deciding to defer it.

Anders Norås
02/06/2007 01:14 PM by
Anders Norås

http://andersnoras.com/blogs/anoras/archive/2007/02/05/hack-bombing-template-for-resharper.aspx

BigJimInDC
02/06/2007 09:20 PM by
BigJimInDC

Why not create a custom attribute, similar to the "Obsolete" one, but named "ThisIsAHack" which takes in a date created and a developer user name. That way, a very simple utility could be created to search an assembly for methods marked as such, and constantly list the ones needing work. This could even be placed into a CI environment, and email the folks who created the hacks on whatever periodic basis to ensure they don't forget. Ultimately, the attribute based mechanism keeps it from potentially hurting the end-user experience, yet allows for an automated approach for indicating and handling hacks.

Ayende Rahien
02/07/2007 07:30 AM by
Ayende Rahien

That requires quite a bit of work for something that should NOT happen regularly.

Contrary to the impression I may have given, I do not tend to use this frequently. :-)

MadMat
02/07/2007 05:13 PM by
MadMat

How about the reverse.... Fix Bombing, where you add a fix but it only works after a specified date?!

Ayende Rahien
02/07/2007 05:57 PM by
Ayende Rahien

Hm, don't laugh, I can think of several reasons to do this, actually.

Tal
02/17/2007 06:22 PM by
Tal

I cannot agree with Adi more, putting exceptions into the code is dangerous enough.

Using time-bombed exceptions is by far riskier. In the best case scenario you risk by loosing precious debugging time while in the worse case scenario I can think of, you risk by losing your client for "unstable" product.

If you wish to remind yourself to fix a bug, use a bug tracking tool of any kind or simply use outlook tasks. If you still want internally in your code, use TODO remarks. Everything else is may result in unwanted results in production and deployment.

http://blog2.tikotzki.com

Comments have been closed on this topic.