Why are debuggers so bad? Why is it that software developers suffer impotent tools for debugging and maintaining their systems while all other aspects of the software development process are so well supported?

We have been used to code generation from domain-specific languages and design notations for at least ten years now. Testers have had plenty of tool support to make their life easier (see for example, Tools for testing, EXE, January 1999). Compiler technology, with project integration, configuration management, and GUI generation is very advanced compared to the rudimentary compile, link, and run sequence of the last decade. Despite this progress, debugger technology remains largely unaffected after almost twenty years of breathtaking progress in all other fields of software development. We are left to fight the bugs of the next millennium (not to mention the Millennium Bug itself) with the primitive debugging technology of the early 1980s.

This lack of technological support becomes all the more surprising when we consider the enormous amount of time spent on debugging and maintenance activities. Most industry estimates put the figure for total development time spent on software maintenance at between 50 and 70 percent.

Other aspects of the development process are well supported. Why is debugging such a poor relation? Perhaps it is simply a matter of image: to admit that we need good debugging tools is to admit failure; good programmers write bug-free programs, don’t they? Alternatively, it could reflect the natural conservatism of tool vendors. Many vendors tell me that they would like to put more sophisticated debugging technology into their static analysers. Sadly, debugging just doesn’t feature on customers’ requirement check lists. There is simply no market pull. It might even be that many developers are unaware of what tools could really do for them if their potential were to be fully unleashed.

In a way, each of these factors acts to amplify the effects of the others. That is, because we do not demand better debugging tools, there is no pressure on tool vendors to develop them. Because these tools go undeveloped, there is little evidence for their true potential. Little evidence, little knowledge, little pressure on the tool vendors, and so the cycle repeats.

You may say ‘but my debugging tools are sophisticated, I’m very happy with the support they provide’. It is true that source maps, multiple break points, walkthroughs, call hierarchies, and symbolic-level output allow us to move unhindered through the execution of our code. We watch its effect on the state of the machine and correlate our observations with the original program. Fine. I’m all in favour of that. But what exactly happens when the program goes wrong; when there is a bug? What does the debugger do? Does it debug? Who identifies the lines of code at fault? Who works out what the replacement code should be? Who checks that the replacement code does not cause harmful ripple effects to percolate through the system?

The debugger merely allows us to watch our program crash in slow motion, and to sift through the wreckage afterwards. The very word ‘debugger’ embodies the most optimistic claim for a system since Sinclair Research’s quixotic advertising material claimed that the 1 KB RAM, ZX81 was capable of controlling a nuclear power station. The truth is, debuggers simply do not remove bugs, they do not even help us to identify them.

Here we have an enormous missed opportunity. There is no reason why the debugger should not acquire the status it deserves. There is a well-developed and mature theory of source code analysis and many prototype implementations that show what could be achieved. It would take comparatively little effort for a tool vendor to incorporate this technology into an existing tool set. Given the amount of time we all spend debugging, it might offer a clear market advantage to the first tool vendor to exploit this latent technology.

Two glaring omissions from current debugging tools are Slicing and Automated Algorithmic Debugging. Slicing (A Piece of Cake, EXE, October 1996, www.cs.tu-bs.de/~krinke/Slicing/slicing.html), allows the developer to home in on those lines of the program that could have contributed to the bug, ignoring those that could not be responsible. Automated Algorithmic Debugging (www.cs.nmsu.edu/~mikau/aadebug.html) automates the ‘decision tree’ process by which we home in on the precise line (or lines) that are responsible for a bug.

Next time you find yourself debugging some code, ask yourself whether you are following a repeated sequence of steps, in a disciplined, rule-based fashion in order to track down a bug. If you are doing this, then that’s great. I’m sure we would all agree that this is the only proven technique for isolating bugs. But are not ‘repeated rule-based steps’ what computers are best at? Did we not invent them so that we would not have to bother with these tedious and error-prone tasks? The process I just described is that of human execution of an algorithm. If there is an algorithm, then it should be part of a tool, so that the human can concentrate on the harder, ‘Eureka’ leap of intuition that describes how to fix the bug.

I have witnessed developers working in Y2K projects, where the main debugging tool for checking for ripple effects produced by date fixes is ‘grep’. The process consists of searching for all variables directly affected, then searching for all those affected by those directly affected and so on, until these ‘effect ripples’ reach the edges of the system. These poor developers are wasting precious time, painstakingly ‘hand automating’ a process that could be performed so much faster and more reliably by machine. It is enough to make Babbage turn in his grave.

Next time you visit a tools fair, it might be worth asking the vendors what support their tool set provides for automating the debugging process. Who knows, with a bit of a push from the developer community, we may get the tools to allow us to do the job.

University of London,