Best way to back out a bad fix?

Question

I fixed a bug in some ftp server code that seemed like a simple, "quick win" fix.

This then highlighted an, er, "undocumented feature" when working in conjunction with a specific ftp client who's behaviour is beyond what the relevant RFCs say, i.e. my solution does not voilate any relevant RFCs.

I then patched the patch to correct the behaviour but my fix(es) still bug me. I'm thinking that I should've seen that the original "quick win" fix in fact wasn't.

Looking back now I see that the patch to the patch was me possibly ignoring the fact that I didn't realise that I was digging myself deeper and deeper into a hole, trying to justify my original patch if you will.

Now, the patched, patched code works fine but I still can't help but thinking that I should go back and fix the original problem with a better solution.

Is going back to fix that now just ego? Or are there cases where looking at the future maintainability justifies the extra work involved?

How do I sell this to management? Maybe just wait and see if another bug is found?

Answer 1

Do you have to really "sell it to management"? I'd say, just fix it properly, document it and why, it should be enough or you just didn't give us enough background info... :)

PS: G'Day Rob !

Answer 2

Sometimes you just have to accept that rework is inevitable and that sometimes, you cannot do the perfect fix. It's part and parcel of everyday development, regardless of whatever Utopian ideals one might hold about software development.

It isn't wrong that you want to go back and correct it, but you have to evaluate the cost/benefit ratio. If fixing it costs time, money, and effort but results in the same functioning software as far as users are concerned, then it's just not worth it. After all, all but the most academic of software projects are there to save money for someone somehow rather than spend it.

Answer 3

As systems get older and larger, this kind of thing can happen frequently. Personally, I find the only viable solution to this to have a large well maintained automated regression suite. Without this, any change is liable to have unforseen consequences.

Note that an automated testing suite is both expensive to create and maintain, so may actually be a harder sell to management.

Answer 4

This particular case doesn't sound like something that could have been anticipated. You can't control an FTP client you didn't write. If your server works within the RFC and you have to introduce a hack to accomodate a client that does not, I don't see how you can beat yourself up about not catching the problem ahead of time.

Answer 5

I always argue that there's never time scheduled to do something twice, so you need to do it right the first time (typically used to counteract Management's desires to introduce shortcuts into the process). Since it's bugging you and you realize it's probably not right, just do it. Otherwise it's likely to come back and haunt you later when the current solution's side-effects break a later addition.

Answer 6

For every project I have, I keep a to do list. It basically is a list of things that need to be done the next time the project is worked on. Sometimes with problems like this the correct/best solution isn't obvious so you may need some time for you to decide on the best solution. As I think about things and come up with ideas I'll add them to my to do list. By the time I actually have to work on it, I'll have several ideas on how to approach it and hopefully I'll have decided on the best method to fix the problem.

The more things you have in production that you have to maintain the less time you have to work on stuff just because you don't like your solution. My compromise is to have a method to remember what I want to do and a way to document my thoughts on how to approach it. When I finally get to work on it I'm better prepared to do it.

I find that going in for that quick fix can actually cause you more problems and take more time then letting it sit for a while before going in for a more thought out solution.

In your specific example I would probably want to backout both patches and apply a new single solution to your original problem that handles the special case client.