When to Stop Debug

Question

I've read the article about fixing bug in this post What process do you normally use when attempting to debug a problem/issue/bug with your software?. One of the answer which I noted is "take a rest" when you have spent too long to try to fix the bug. I believe it is a good idea too.

But sometime I am in a tight deadline when some mysterious bug appears. When this is happened I tend to think to rewrite the code rather than spending more time to fix the bug.

My question is, when will you think it is better to rewrite the code rather than fix it? Or what criteria can we use to determine whether to keep fix the bug or rewrite the code?

Answer 1

If you are on a tight deadline and decide to rewrite the code, how do you know you wouldn't introduce more bugs than what you are trying to fix? And after you go through the rewrite, for all you know, the same bug might still be there. What if the root cause of the problem happens to be your understanding of some external API? Your code might be new, but your understanding of interacting with other components is the same.

I would advise to NEVER rewrite any code just because it has a bug that you don't understand. As software engineers, significant portion of our jobs is debugging. And there should be no reason why a bug can't be found. Keep digging and unwrapping layers. Seek out help of tools such as logging (homegrown or frameworks), debuggers and so on. These are the types of experiences that make you a better developer. Not only you will gain skills which you are currently missing, but you will also gain insight into what not to do in the future. If all else fails, you start the painstaking process of manual binary search (disable half the code and see how that affects the bug, then keep doing the subdivision until you narrow it down enough)

If you need to take a break, take it. Another thing that helps is to sit down with a coworker and explain to him what you've found and your steps. a) your co-worker might have additional advice and b) you use him as a sounding board and sometimes when you speak out loud, you might realize what you've been overlooking yourself.

Answer 2

Changing the code in any way imposes a risk of introducing new bugs into the code. The bigger the changes, the bigger the risk. You can mitigate that risk via unit (and integration/system/...) testing (but can't ever eliminate it completely).

Obviously, a total rewrite has a significantly higher risk than just fixing a specific bug. In order to create a proper fix, you have to understand the problem and the solution well enough so that fixing one issue doesn't break some other use case. But so is the case for a rewrite. If you don't understand what's going on during debugging, obviously the code in question is complex, so rewriting it is going to be far from trivial, and usually takes way more time you would assume. Which, under a tight deadline, is not good news...

Moreover, being tired and under pressure always increases the risk of making bad decisions and mistakes, thus causing more bugs.

So I personally would strongly prefer debugging and fixing the concrete bug rather than rewriting, except when the code in question is really really terrible and I have a clear specification (in the form of documents and/or unit tests) of what it is supposed to do and I have enough time to do it properly.

(Note also that if the code is really so terrible, it is exceedingly rare that it is properly documented and/or unit tested. In this case, one needs even more time to first construct a proper unit test suite to "record" the behaviour of the current code, to be able to verify that the new implementation reproduces it faithfully in every aspect except the bug fix.)

If you are stuck with your current approach, it is indeed a good idea to take a rest and do something else to relax your brain and allow your subconscious to work on the problem in peace. It is also useful to ask help from a colleague (or StackOverflow). See this earlier related thread for more details:

Dealing with frustration when things don't work

Answer 3

A proper preparation before delving directly into code would never need you to rewrite it. If you are rewriting your code often it means that the method you have chosen is lacking proper analysis of requirement and/or technology and/or approach. Do not underestimate the art of Software Engineering. It saves lot of time and brain damage.

Keep commenting, versioning could also save you some rework.

As for when you can rewrite the code than to debug. Do it only if

1. Piece of code is small enough.
2. You know that it would not solve the problem
3. You are working on someone else's uncommented code (it again has to be small)
4. You have lot of time and are getting shivers just by looking at the existing code. :)

Answer 4

My question is, when will you think it is better to rewrite the code rather than fix it?

I'm tempted to say "never". The problem is: Rewriting may seem easier, but experience tells that usually new code will have new bugs. So you'll probably replace one bug with several new ones.

Furthermore, if you don't understand why the bug occurs, what tells you that your rewrite will not accidentally contain the same bug (maybe it was a design error, or a misunderstanding on your part).

There may be situations where code is so buggy that it's just not worth salvaging, but these are very rare. I have only had it happen once or twice in almost ten years of development work.

This really only applies to code that is so buggy that it practically does not work at all. As long as the code mostly works, I would never rewrite it, no matter how ugly or complicated it is.