Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Hack bombing

time to read 2 min | 335 words

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.

   //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.



Sounds horrible to me:


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 ;)


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

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



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

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. :-)


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

Ayende Rahien

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


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.


Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats