And yet, despite decades of research and practice, most developers have weak debugging skills, don't know how to property use debugging tools, and still rely in basic print statements (<ahref="#beller">Beller et al. 2018</a>).
<p>To start, you have to <strong>reproduce</strong> the failure. Failure reproduction is a matter of identifying inputs to the program (whether data it receives upon being executed, user inputs, network traffic, or any other form of input) that causes the failure to occur. If you found this failure while <em>you</em> were executing the program, then you're lucky: you should be able to repeat whatever you just did and identify the inputs or series of inputs that caused the problem, giving you a way of testing that the program no longer fails once you've fixed the defect. If someone else was the one executing the program (for example, a user, or someone on your team), you better hope that they reported clear steps for reproducing the problem. When bug reports lack clear reproduction steps, bugs often can't be fixed (<ahref="#bettenburg">Bettenburg et al. 2008</a>).</p>
<p>If you can reproduce the problem, the next challenge is to <strong>localize</strong> the defect, trying to identify the cause of the failure in code. There are many different strategies for localizing defects. At the highest level, one can think of this process as a hypothesis testing activity (<ahref="#gilmore">Gilmore 1991</a>):</p>
<ol>
<li>Observe failure</li>
<li>Form hypothesis of cause of failure</li>
<li>Devise a way to test hypothesis, such as analyzing the code you believe caused it or executing the program with the reproduction steps and stopping at the line you believe is wrong.</li>
<li>If the hypothesis was supported (meaning the program failed for the reason you thought it did), stop. Otherwise, return to 1.</li>
</ol>
<p>The problems with the strategy above are numerous. First, what if you can't think of a possible cause? Second, what if your hypothesis is way off? You could spend <em>hours</em> generating hypotheses that are completely off base, effectively analyzing all of your code before finding the defect.</p>
<p>The nice thing about this strategy is that you're <em>guaranteed</em> to find the defect if you can accurately identify the causes of each line of code contributing to the failure. It still requires you to analyze each line of code and potentially execute to it in order to inspect what might be wrong, but it requires potentially less work than guessing. My dissertation work investigated how to automate this strategy, allowing you to simply click on the fault output and then immediately see all upstream causes of it (<ahref="#ko">Ko & Myers 2008</a>).</p>
<p>Yet another strategy called <em>delta debugging</em> is to compare successful and failing executions of the program (<ahref="#zeller">Zeller 2002</a>):</p>
<ol>
<li>Identify a successful set of inputs</li>
<li>Identify a failing set of inputs</li>
<li>Compare the differences in state from the successful and failing executions</li>
<li>Identify a change to input that minimizes the differences in states between the two executions</li>
<li>Variables and values that are different in these two executions contain the defect</li>
</ol>
<p>This is a powerful strategy, but only when you have successful inputs and when you can automate comparing runs and identifying changes to inputs.</p>
<p>One of the simplest strategies is to work forward:</p>
<ol>
<li>Execute the program with the reproduction steps</li>
<li>Step forward one instruction at a time until the program deviates from intended behavior</li>
<li>This step that deviates or one of the previous steps caused the failure</li>
</ol>
<p>This strategy is easy to follow, but can take a <em>long</em> time because there are so many instructions that can execute.</p>
<p>For particularly complex software, it can sometimes be necessary to debug with the help of teammates, helping to generate hypotheses, identify more effective search strategies, or rule out the influence of particular components in a bug (<ahref="#aranda">Aranda and Venolia 2009</a>).</p>
Ultimately, all of these strategies are essentially search algorithms, seeking the events that occurred while a program executed with a particular set of inputs that caused its output to be incorrect.
Because programs execution millions and potentially billions of instructions, these strategies are necessary to reduce the scope of your search.
This is where debugging <strong>tools</strong> come in: if you can find a tool that supports an effective strategy, then your work to search through those millions and billions of instructions will be greatly accelerated.
This might be a print statement, a breakpoint debugger, a performance profiler, or one of the many advanced debugging tools beginning to emerge from research.
It turns out that there are usually many ways to repair a defect.
How professional developers fix defects depends a lot on the circumstances: if they're near a release, they may not even fix it if it's too risky; if there's no pressure, and the fix requires major changes, they may refactor or even redesign the program to prevent the failure (<ahref="#murphyhill">Murphy-Hill et al. 2013</a>).
This can be a delicate, risky process: in one study of open source operating systems bug fixes, 27% of the incorrect fixes were made by developers who had never read the source code files they changed, suggesting that key to correct fixes is a deep comprehension of exactly how the defective code is intended to behave (<ahref="#yin">Yin et al. 2011</a>).
</p>
<p>
This risks suggest the importance of <strong>impact analysis</strong>, the activity of systematically and precisely analyzing the consequences of some proposed fix.
This can involve analyzing dependencies that are affected by a bug fix, re-running manual and automated tests, and perhaps even running users tests to ensure that the way in which you fixed a bug does not inadvertently introduce problems with usability or workflow.
Debugging is therefore like surgery: slow, methodical, purposeful, and risk-averse.
<pid="aranda">Jorge Aranda and Gina Venolia. 2009. <ahref="http://dx.doi.org/10.1109/ICSE.2009.5070530">The secret life of bugs: Going past the errors and omissions in software repositories</a>. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 298-308.</p>
<pid="beller">Beller, M., Spruit, N., Spinellis, D., & Zaidman, A. (2018, May). <ahref="https://doi.org/10.1145/3180155.3180175">On the dichotomy of debugging behavior among programmers</a>. In 2018 IEEE/ACM 40th International Conference on Software Engineering (ICSE) (pp. 572-583).<p>
<pid="bettenburg">Nicolas Bettenburg, Sascha Just, Adrian Schröter, Cathrin Weiss, Rahul Premraj, and Thomas Zimmermann. 2008. <ahref="http://dx.doi.org/10.1145/1453101.1453146">What makes a good bug report?</a> In Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering (SIGSOFT '08/FSE-16). ACM, New York, NY, USA, 308-318.</p>
<pid="gilmore">Gilmore, D. (1991). <ahref="http://www.sciencedirect.com/science/article/pii/000169189190009O">Models of debugging</a>. Acta Psychologica, 78, 151-172.</p>
<pid="ko">Amy J. Ko and Brad A. Myers. 2008. <ahref="http://dx.doi.org/10.1145/1368088.1368130">Debugging reinvented: asking and answering why and why not questions about program behavior</a>. In Proceedings of the 30th international conference on Software engineering (ICSE '08). ACM, New York, NY, USA, 301-310.</p>
<pid="murphyhill">Emerson Murphy-Hill, Thomas Zimmermann, Christian Bird, and Nachiappan Nagappan. 2013. <ahref="http://dl.acm.org/citation.cfm?id=2486833">The design of bug fixes</a>. In Proceedings of the 2013 International Conference on Software Engineering (ICSE '13). IEEE Press, Piscataway, NJ, USA, 332-341.</p>
<pid="yin">Zuoning Yin, Ding Yuan, Yuanyuan Zhou, Shankar Pasupathy, and Lakshmi Bairavasundaram. 2011. <ahref="http://dx.doi.org/10.1145/2025113.2025121">How do fixes become bugs?</a> In Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering (ESEC/FSE '11). ACM, New York, NY, USA, 26-36.</p>
<pid="zeller">Andreas Zeller. 2002. <ahref="http://dx.doi.org/10.1145/587051.587053">Isolating cause-effect chains from computer programs</a>. In Proceedings of the 10th ACM SIGSOFT symposium on Foundations of software engineering (SIGSOFT '02/FSE-10). ACM, New York, NY, USA, 1-10.</p>
<pid="zeller2">Zeller, A. (2009). <ahref="https://books.google.com/books?id=_63Bm4LAdDIC&lpg=PP1&ots=TAzo27xsK-&dq=why%20programs%20fail&lr&pg=PP1#v=onepage&q=why%20programs%20fail&f=false">Why programs fail: a guide to systematic debugging</a>. Elsevier.</p>
