Debugging is a challenging and interesting aspect of software engineering. Iíve often noticed project stakeholders sulking about not having smart engineers--the so-called human debuggers--in among their team of bright developers. Iím sure every one of you has come across such situations.
Great developers need not be successful debuggers. Sometimes quality assurance (QA) engineers are more successful in debugging than developers. More interestingly, the synergy increases when a pair of engineers (a developer and a QA engineer) does debugging. We can call it pair-debugging and I am sure those who have spent days and nights debugging would appreciate what it takes to debug errors that are very simple but take huge efforts to debug. More interestingly, when a developer spends several hours on debugging an issue, naturally he collaborates or joins hands with a QA engineer to hit it straight.
In my effort to understand debugging, Iíve found it helpful to collect and compare the different definitions of debugging that Iíve gathered mostly from the Internet. In this way, I was able to formuate my thoughts on the subject. Here is my collection of definitions of debugging I found on the web:
The process of finding and removing the causes of failures in software.
Detecting, tracing, and eliminating mistakes in programs and other software.
The process of discovering and correcting bugs in a program.
The task of determining the exact nature and location of a software defect and fixing it.
Tracking down and fixing programming errors in an application under development.
The act of correcting errors during the development process.
The process of identifying a program error and the circumstances in which the error occurs, locating the source(s) of the error in the program and fixing the error.
The process of eliminating errors (or "bugs") from a computer program.
A process of testing a program and figuring out where the problems are to make the program works as intended. Some bugs are like viruses but are removed by the skilled programmer as they realize the errors in their programming statements.
It denotes a procedure of detecting, locating, and removing mistakes or imperfections from a computer program or any new system.
Debugging is to remove all the errors from a program.
Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another.
Thanks for the comments. I had a look at your poster and it is quiet simple and practical. Thanks for sharing. Debugging continues to consume significant efforts (and hence cost) among all Software Engineering activities. Following such rules and asking critical questions will benefit engineers who spend long hours in debugging.
I devoted a whole book, appropriately titled "Debugging" to the subject. It too is a lighter attempt to enable better debugging. But it does work -- all of the general guidelines I've seen are still covered by the 9 rules and their corollaries. So for example, Larry M.'s comment is covered well by rule 3, Quit Thinking and Look. The 9 rules are available on a poster from www.debuggingrules.com.
-- Dave Agans
Thanks for reading my blog. I liked your quote very much. The ability to see or visualize the right thing is very critical to debugging.
My Product Engineering Blog: http://www.mindtree.com/blogs/category/software-product-engineering
I once wrote an article on debugging that included an observation on how a good debugger operates. If I may be allowed to (probably mis)quote myself:
"A good debugger sees what is, not what he expects it to be, what he thinks it must be, or what he wants it to be".
Literally the developer is their own worst enemy when debugging a system. They know what it is supposed to do, so they come in with expectations that this is what it must be doing. This is why a different person sees bugs that a developer will miss.
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for todayís commercial processor giants such as Intel, ARM and Imagination Technologies.