+972 52-548-6969
Defending Hack Bombing
Adi posted a rebuttal to my suggestion about Hack Bombing:
My point of view is that most developers (certainly I am included in this) will ignore "minor" issues when they focus on a bigger goal. The problem is that those "minor" issues tend to get not so minor very fast. I find that the easiest way to make sure that something is done is to ensure that you cannot work without it. Some examples:
- All the pages in my current project should inherit from a common BasePage class, when the application is starting up, it will verify that all the types inheriting from Page are also inheriting from BasePage. If it finds that a type that inherit Page not through BasePage, it throws an exception telling the developer that type so and so isn't inheriting from BasePage.
- A page that is issuing too many database queries is consider a failure, and will throw, telling the developer that there is a performance problem with this page that they need to take care of. There are ways around that by appending ?Hack=true to the page, but this is obviously something that demands attention from the developer working on the page.
And if you didn't get to your "To do" comments because you were busy doing something more important, using a time bomb will just force you to break your important task, replacing the time bomb with a "To do" comment and going back to that task....
Yes, if I didn't get it fixed in time, I will suddenly have to shift gears and fix this (or deffer it again). The issue here is not trying to ensure perfection, the issue here is:
- Putting the bomb there makes it much more likely that I will remember it in time.
- Actually getting hit by the bomb means that I need to fix it now, or to actively do something that is bad (deffer it again). [If I replace the time bomb with a todo something is very wrong.]
Either way, my end result is set, this will get fixed. The issue of not hitting that code path until QA or production is note something that I am worried about, since I have got tests that cover this area in the code, and I know that I will get a build failure tomorrow if this is not fixed, so there is no way for it to slip by me.
The scenario that Adi describe, a developer checking an exception in the code path of many other developers and inteferring with their work is not something that I need to worry about in my team. When / if this happens, either me or one of the other members will fix it (if not earlier). I consider this superior to TODO because TODO are often ignored, and bugs can triaged by "we will fix it when it breaks, let us do MORE features".
Update: Where do I think it it appropriate to put this? Not in code that is missing features, but in code that is passing the unit tests, but is not working correctly internally. For instnace:
{
TimeBombHack.Until(new DateTime(2007,2,10), "There is a better way, I am sure, but this is what I found on google. Need to get back to it...");
try
{
DateTime.Parse(date);
return true;
}
catch
{
return false;
}
}
Vs the good implementation:
public bool IsValidDate(string date)
{
DateTime dateTime;
return DateTime.TryParse(date, out dateTime);
}
Functionaly, they are doing the same thing. But the second one is clearly the prefered way to go.
Comments
Why not create a unit test that fails because the feature is not implemented?
Because this isn't an issue of a missing feature.
It is an issue of a broken implementation of a feature.
Example:
public bool IsValidDate(string date)
{
try
{
}
catch
{
}
}
The above is working code, and it will be able to go through any unit test that a well written one will.
The problem is that the implementation is horrible and has to be fixed, that is the place for this.
I think hack bombing has plenty of merit - I've worked on projects where people tend to keep pushing for new features before tidying up the old ones - my only concern is that there's a chance (albeit slim depending on your delivery cycle) that this could end up deployed with a customer...
Perhaps for release builds the functionality could be different (logging warnings instead of throwing exceptions) through some conditional #defines... or do you think this breaks the "spirit" of the bomb?
If this is something that would ever really bother me I could just slap a [Conditional] on it and manage it this way.
Making sure you remember something is easy. For example, in the agile methodology Scrum you add a backlog item. A simple alternative is to create a new task in your Outlook.
Regarding the second objective, the hack bombs method sounds to me like going into a diet by telling your dentist to seal your jaw shut instead of striving to change your eating habits.
It means you don't trust yourself to make the right choice when the time comes.
Instead of forcing yourself to handle those task in advance, you should train yourself to record them and finding the time to address them voluntarily.
Comment preview