Find the difference – spot the bug

Every developer has been at a point when a defect is found in software he has been working on, in fact a major part of every software developer is fixing bugs.

A software bug (or just “bug”) is an error, flaw, mistake, failure, fault or “undocumented feature” in a computer program that prevents it from behaving as intended (e.g., producing an incorrect or unexpected result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.

From Wikipedia - Software bug

The first order of business is to find what caused it, for that we need to discover what piece of code needs to be rewritten in order for the software to work properly. And so if we want to find a software defect all we need to ask ourselves is:

What is the difference between the code that used to work and the code right now.

[From Paradesh Baata’s Blog]

Sometimes we can know the location of the bug by knowing our project very well but sometimes we have no clear idea of the exact code that could cause it.

Using simple practices and common tools can decrease the time spend on finding (and fixing) the bug.

Early discovery

In the ideal world when a new bug is entered into our code we would know about it - unfortunately for most of us we do not work in that place where each and every bug is discovered a few minuets after we’ve created it.

What we can do to improve our odds greatly is use unit tests as part of the software development process.
If our project has a good coverage of unit tests all we need to do is run them and see which tests fails and by a process of elimination we might know the code that caused the defect.
The second most valuable tool to find bugs as soon as they enter our system is using a continues integration:

Maintain a code repository
Automate the build
Make your build self-testing
Everyone commits every day
Every commit (to mainline) should be built
Keep the build fast
Test in a clone of the production environment
Make it easy to get the latest deliverables
Everyone can see the results of the latest build

And so by having a server that that runs all of our project’s unit tests we improve our chance of catching defects soon and isolate the problematic code.

Find when the bug was created – when the code stopped working

What if you project doesn’t have unit tests? what if the unit tests didn’t catch the bug and it was discovered by another developer, the QA department or even a customer – what can we do now?

Hopefully the bug report is detailed enough in that case we can try to reproduce it with previous versions of the code. When a version that don’t reproduce the bug is found – we know that the version after it has the code that caused that defect. Now we need to do some thinking and try to figure what is the difference between that version and the versions after it.

The number one tool that can helps us here is a proper source control that would help us retrieve previous versions of the application. It still amazes me that some software companies do not have a proper source control set up but in that case it is up to the developer to keep previous versions of his code in some secure location.

Conclusion

Even after we have an idea of where the defect is and what caused it most of the time we’ll still need to debug that code to verify our thesis. but by eliminating the places the bug isn’t we can reduce the time spent on finding it. There are some times when nothing helps and all we can do is debug our code line by line hoping to find the problem but by properly understanding our code and using simple elimination we can make it easier.

Labels: Thoughts, Tips and Tricks