I'm trying to solve a complex bug in our codebase , but the problem seems to be coming from a lot of places to the point that i dont know what to change first .

do you have any procedure or guidelines todo in such a situation ?

  • What do you mean by "coming from a lot of places"?
    – yoozer8
    Sep 1, 2011 at 14:03
  • that i identified many different portion of code that are introducing the bug
    – Mona
    Sep 1, 2011 at 14:06
  • Doesn't sound very DRY...
    – yoozer8
    Sep 1, 2011 at 14:11
  • I doubt it's really coming from multiple places. You're probably looking at corruption that stomps on something. Sep 1, 2011 at 22:57

5 Answers 5


Don't start by making changes, start by reproducing the bug in unit tests. After that change the code so that the unit test passes instead of fails.

Sounds like you have multiple bugs, not just one, start at the lowest level, identify specific bugs, write failing unit tests and fix.


First, analyze the problem. Don't start making changes until you understand the codebase. Start by reading the design documentation (class, sequence, and communication diagrams would be a good start) and in code comments. Use logging (that's what TRACE and DEBUG level logging is for), a debugger to step through code and watch variables as they change. This is also a good time to make notes if the design documentation and/or in-code comments are wrong - fix them for future developers.

Second, once you understand the codebase, come up with test cases to identify the problem and confirm that you've fixed this. There might be unit tests, system tests, and acceptance tests associated with the problem that need to be created or revised. You're going to want to make sure that you have fixed the defect, that your fixes don't introduce other defects, and that this defect doesn't appear again as the result of a regression.

Finally, you can fix the defect. Run your tests to confirm, and if any documentation is affected, either update it or file a defect against the documentation so that any changes you made are reflected for the user or future developers.


the problem seems to be coming from a lot of places

Fortunately, this is probably false. Bugs can be caused by all sorts of different things, but when you see a bug cropping up all over the place, you can bet that the instances of that bug all lead back to one place. This place could be some corrupted data in a SQL table, a funky setting in a config file, or a piece of bad application logic that a lot of components touch. It could also be a million other things, but the key is always to figure out what the different instances of the bug have in common. Tools can be a huge help. Use a SQL profiler for data heavy stuff. I recently had to fix a proprietary system that had close to 15,000 stored procedures. One of them went haywire during an update that conflicted with some of the modifications I had made to the system. Without a SQL profiler, this fix would have been more or less impossible. If you rule out a data issue, your number one goal is to find that line of code where the bug is created. With a good trace log, a debugger, and some common sense, you can track down just about any bug.

  • Or it just means there are multiple bugs...
    – riwalk
    Sep 1, 2011 at 14:23
  • @Stargazer - from the OP's comment up top, I think you might be right. Saying that there are "many different portions of code that are introducing the bug" pretty much means there are many bugs. Sep 1, 2011 at 14:27

To solve complex multiple bugs ("coming from a lot of places"):

This is the general tried and tested approach I take:

  • Take the section of code-base in question
  • Break this section into sub sections
  • Using an initial set of input data, cascade this data/event through this isolated sub section of code. You need to prove that the expected "effect" (return values/events) match what you expect. If this fails fix it untill it does
  • repeat above for the next sub-section using the "effects" (return values/events) from the previous subsection
  • Once all sub-sections are completed, re-assembling the sub-sections back should now fix all the multiple-bugs

1) STOP!!!

2) Debug mode ON

3) Try until you reproduce the bug

4) Inspect logs and debuggers

5) Change code accordingly

6) Try to reproduce the same bug again

7) Go back to step 3 unless the bug has been fixed.

From now on, you will include this particular bug test together with your other tests, as you want to be sure it won't show up again. Forget about "But that's not gonna happen again!".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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