Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been working on a project comprising of databases, and I recently received a bug report for the remote execution of some queries.

Usually, you try to find out the actual cause for the bug to occur and then fix it.
But sometimes what I do when I'm fed up of doing some research (and can't find suitable information on the internet) is just change the logic, which takes me much less time compared to the other option.

Is this approach correct, or should I try to fix the original bug involving more R&D?

share|improve this question
4  
So in stead of tracking down and solving the issue, you're hiding it? As in, you're not 100% sure that the problem is not there anymore? That doesn't sound good. –  Bart May 29 '12 at 9:51
    
By replacing the logic you're possibly introducing new bugs. And possibly breaking unit tests. IMO, not recomended. –  Amadeus Hein May 29 '12 at 9:52
    
@Bart its not about hiding the issue, I just change the working so the buggy part is eliminated from the code.* in my case its just change of some queries*. –  Shirish11 May 29 '12 at 9:54
1  
I'm just trying to understand you, but how can you be sure you've "eliminated the buggy part" when you seem to indicate you've given up on finding the cause of the bug? To me it sounds like a workaround rather than a solution. –  Bart May 29 '12 at 9:55
4  
+1. There is nothing so bad that it cannot be used as a bad example. –  Doc Brown May 29 '12 at 13:18

8 Answers 8

up vote 13 down vote accepted

In my head this raises alarmbells.

Granted, I am not a database programmer. My work is not nearly as security critical for example. But when you say

But sometimes what I do is fed up of doing some research (cant find suitable information on the internet) I just change the logic which takes me much less time as compared to the other.

I get the feeling that you know yourself that the approach you're taking is most likely not the one you should be taking.

To me it seems you're treating symptoms rather than the underlying problem. And I can't say I have never done so. But experience tells me that, although it might never happen, this will usually come back to bite you in places you don't want to be bitten.

I would say that your last sentence is correct. Take the time to find and fix the original bug. You can't be sure you've fixed the issue if you haven't figured out what the issue was in the first place.

Any workaround might cosmetically solve your problem, but could as well introduce side-effects you hadn't thought of, besides possibly still leaving your system exposed to the original problem.

share|improve this answer
    
I have found that there are some cases where code is simply just bad. It is that situation where all the bug reports appear to be in a particular set of code that you know is not particularly good; where each bug fix is followed by a new unrelated bug report. In those cases, nuking from orbit and rewriting can be the best approach. (Assuming you understand what it is supposed to do, if not what it is doing.) –  Steven Burnap May 30 '12 at 21:09
    
Oh sure. If it's an isolated section of code to which you have (without a doubt) narrowed down all problems and you're certain there will be no side-effects to its removal, nuke the damned thing. But you should be pretty damn certain. –  Bart May 30 '12 at 21:27
    
I've done it in bigger sections of code and been glad of it. Sometimes code is written so badly that it is better to risk new bugs than to try to batter it into shape. –  Steven Burnap May 30 '12 at 22:15

If you can just throw away the part of the code which contains the bug, and the software product is still functional and conform to the original requirements, then you shouldn't have written this part of the code at all in the first place.

So yes, if you can solve a bug while removing the code that you don't need, this is a good approach. You may still ask yourself why you've written the code that you don't need.

share|improve this answer

"Fixing" a bug by fiddling with things and changing them so that the non-understood problem goes away is a terrible strategy.

It is bad because:

a) you've learned nothing about a potential weakness in your system or the software/frameworks/resources you're using

b) by swapping things around you might just introduce new issues

If you're on a really tight deadline and your approach is your best hope in the time available, then it can get you out of a tight spot (possibly). But I'd only do that as a last chance option, and then go back and find out what the problem is after the deadline.

This actually remind me of an ex-colleague who didn't quite understand boolean logic (yes, really). He'd jigger around with his boolean expressions (nesting ands and ors) until something worked. Even if you can get something working by doing such things, you've not understood the problem, and you're also relying to a certain degree on luck.

share|improve this answer

Indeed, this would not be the correct way to go at this. In my opinion this will only raise the chance of creating new bugs or the chance of someone finding this same bug again.

Bugs should be fixed, not worked around.

Of course I'm not sure what you replaced it with. If you replaced a faulty query with a correct one you could call it a fix. If you wrote a completely different one it would be a work around if you ask me.

Better try and fix the bug to make sure it doesn't show it's head again!

share|improve this answer

Your approach is valuable as long as you can justify why it works. You seem to be unsure enough to ask here.

You performed one part of the justification: check that the buggy query (failing test) is no longer buggy (test passes).

The other part of the justification is to check that no other query (every test) becomes buggy (all tests pass).

Only then you can trust your approach.

share|improve this answer

Good thing about your approach is that one can focus on things requiring immediate attention. Side-stepping to investigate what initially went wrong might take a lot of time and push completion of the bugfix far beyond deadlines.

Bad thing is that potentially important side issue remains unresolved. Since you don't know what really went wrong, there is a chance that this "wrong" bites you painfully in the middle of even more important and urgent bug fix.

To handle "collisions" like that, issue tracker appears to be a tool made in heaven. In cases like you describe, I simply "fork" a new dedicated ticket to handle side issue I discovered. That dedicated ticket hangs in there until I am done with current fix - after that, I return to new ticket and sort it out.

Issue 1234: investigate root cause of Issue 1233 - find out what went wrong with <old logic>

  • Above trick with "forking a ticket" is a practical application of decomposition principles. Decomposition is known as a powerful strategy in software design; in my experience it has proven to be quite useful in bug tracking, too.
share|improve this answer

If you mean that instead of analyzing a pile of WTF, you discard it, rewrite, and test, then your approach makes sense to me. Broken code has no value.

I have often answered the question "What's wrong with this code?" with "Who cares? Here is a solution."

share|improve this answer

What I usually try to do when I'm fixing a bug is:

  • Confirm that the bug exists. Preferrably I'll "document" the bug by writing a test case that fails due to the bug. This also has the advantage of knowing that this test case now will be part of the test suite of the product, so if the bug pops up again this will be confirmed by the regression tests (assuming that you run regression tests of course!).
  • Familiarize myself with the code causing the problem. If I'm still unsure if I'll break anything else by my bug fix (oh the irony) I'll write more test cases to document the behavior of the given code. This not only benefits me but also others who will go through the same code eventually.
  • Fix the bug.
  • Ensure that all the test cases affecting my bug fix passes.

Basically I try to keep a safety net for all my bug fixes just to make sure that I don't cause additional bugs. I also understand that it sometimes will feel easier to just change the code and be done with it, but at the same time it can definitely be worth the initial time investment, since not only you, but also others who deal with the same code will benefit from having an increased test coverage.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.