Tracking a debug

There is bug in my code. Not released code, this is code under development and the bug is interesting as refuses to submit to logical analysis. Tracking which module is replacing text is important, understanding why that is occurring may be the only way to fix what is happening, as opposed to fixing what I think is happening.

The final law of debugging may apply. When all logic seems to fail, the final law of debugging is this:

if you do not know what is causing the problem you are not be looking at the problem

One examines debugging iteration results for the clues to the logic. Post analysis of what a program is doing is often better than trying to "watch it".

Walk through step by step if necessary.

Individual testers improve software development by a significant degree. Programmers make terrible testers but this is simply due to the kind of thinking involved. Testing does not make terrible programmers, however.

Programming is best done from established rules and structures that provide a sound basis for proceeding. Without that solid analysis assumptions would start to creep in.

Programmers often create bugs by shortcutting or neglecting to complete processes. If every piece of code were diagrammed and written with exact application to detail - bugs may still exist, but only the difficult ones.

Finding all bugs and correcting ONLY them is absolutely vital. Programmers of course must test stuff before sending it to be tested by others. But if programmers are to alpha test software and they also wear the analysis hat, strict attention to not introducing new ideas from regression testing have to be kept out of that release iteration.

But sometimes a programmer faces a bug that seems impossible. This is a trap. Looking at test data, and verification against raw data seems a natural and necessary enough testing activity for validation.

The programmer looks at the log, and the database and notices that the log seems to reflect the database, but the display - is doing something else. So the bug must be in the code. Programmer stares at the code in disbelief. Swears "there is nothing wrong with my code, is there!?".

The code looks simple, there is simply nothing wrong there. But the programmer curses and runs it again not believing eyes that are now glaring at you "you see? as the same failing code is run again just in case you did not believe the test, either.

The programmer is reacting to the discrepancy and not trusting instinct. Think again - nothing is wrong with the code. The problem must be elsewhere. Take a 30 second break from looking at it, and stop trying to defend your code - it is right - look in another module of your code. Probably earlier in the code, but not always.

The Scientific method of debugging does not rely upon anything other than simple observation of what is.