+972 52-548-6969
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
Sounds horrible to me:
http://dotmad.blogspot.com/2007/02/hack-bombing-is-horrible-idea.html
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 ;)
Defending Hack Bombing
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?
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.
http://andersnoras.com/blogs/anoras/archive/2007/02/05/hack-bombing-template-for-resharper.aspx
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.
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?!
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.
http://blog2.tikotzki.com
Comment preview