Bug(ging) and debugging
At the beginning of my PhD, I read two interesting books about debuggers. One by J. Rosenberg, How Debuggers Work: Algorithms, Data Structures, and Architecture which describe the internal algorithms of interactive debuggers; and another by A. Zeller, WHY PROGRAMS FAIL: A Guide to Systematic Debugging that discusses how programmers introduce bugs in their applications. And in particular, in the latter book, Zeller explains what is a bug, through four different steps:
It's important to have these four step in mind when you develop and debug, as although you may have a problem (a defect) in your code, if step 4 (or 2) is never executed it won't be visible in your application .... until the execution takes another code path.
Likewise, it may be easy to 'fix' a failure, but that doesn't mean that you problem is actually resolved.
I just read another though on debugging that I quite like, that compares it with Sherlock Homes' investigation technique:
Debugging is indeed reasoning backwards, you see consequences, a failure (or a murder), and you investigate on what the causes can be.
I don't agree with his conclusion though,
as I think that both methods are just complementary. You investigate on what the causes can be, then you make hypothesis and you try to validate or disprove them. The better investigator you are, the easier it will be to formulate hypotheses and prove them right and useful!
1. The programmer creates a defect. A defect is a piece of the code that can cause an infection. Because the defect is part of the code, and because every code is initially written by a programmer, the defect is technically created by the programmer.
2. The defect causes an infection. The program is executed, and with it the defect. The defect now creates an infection—that is, after execution of the defect, the program state differs from what the programmer intended. A defect in the code does not necessarily cause an infection. The defective code must be executed, and it must be executed under such conditions that the infection actually occurs.
3. The infection propagates. Most functions result in errors when fed with erroneous input. As the remaining program execution accesses the state, it generates further infections that can spread into later program states. An infection need not, however, propagate continuously. It may be overwritten, masked, or corrected by some later program action.
4. The infection causes a failure. A failure is an externally observable error in the program behavior. It is caused by an infection in the program state.
It's important to have these four step in mind when you develop and debug, as although you may have a problem (a defect) in your code, if step 4 (or 2) is never executed it won't be visible in your application .... until the execution takes another code path.
Likewise, it may be easy to 'fix' a failure, but that doesn't mean that you problem is actually resolved.
I just read another though on debugging that I quite like, that compares it with Sherlock Homes' investigation technique:
How do you debug?
> Most people, if you describe a train of events to them, will tell you what the result would be. They can put those events together in their minds, and argue from them that something will come to pass. There are few people, however, who, if you told them a result, would be able to evolve from their own inner consciousness what the steps were which led up to that result. This power is what I mean when I talk of reasoning backwards, or analytically.
>
>Sherlock Holmes A Study in Scarlet, by Sir Arthur Conan Doyle
Debugging is indeed reasoning backwards, you see consequences, a failure (or a murder), and you investigate on what the causes can be.
I don't agree with his conclusion though,
The Holmes method of debugging is superior, I think, to the scientific method of debugging because debugging isn’t just a science. There’s an art to knowing where to look and what data is needed. This comes from experience and is as much intuition as it is logic. Practice debugging and you will be a better debugger.
as I think that both methods are just complementary. You investigate on what the causes can be, then you make hypothesis and you try to validate or disprove them. The better investigator you are, the easier it will be to formulate hypotheses and prove them right and useful!
