Skip to main content

Debugging

Debugging, Debuggers and Dbux

Debugging is an investigative process. When facing down most non-trivial bugs, we usually start by looking at available data (e.g. logs), guess potential places that might be at fault, rinse and repeat, in order to slowly circle in on the root-cause.

In order to do so, most developers still overwhelmingly resort to print debugging. Some developers sometimes1 use the "traditional debugger": it allows placing breakpoints and step through the program in order to investigate highly localized data (such as variable values and the call-stack) at a specific place and time in the execution. It can be a fantastic tool, if you know where to look, and, ideally, if the root cause is downstream from observed symptoms. Sadly, most bugs don't work like that. Often times when we observe a failure, we have to go back in time to find its cause. Most implementations2 of the traditional debugger do not support that. We argue: this approach to debugging is not very effective, and has not really changed over the past several decades. That is why with Dbux, we sought out to look for new ways of approaching debugging.

Dbux is an omniscient debugger, meaning it automatically gathers and visualizes your application's runtime behavior, and makes it interactive. The term "omniscient" (meaning "all-knowing") is a quirky exaggeration (it does not know your grandma's birthday). By default, it records the beginning and end of all executed files and functions, all asynchronous events and the entire trace log, meaning (almost) all statements and expressions and their values.

All that data is then available for the developer to inspect and interact with, using a variety of dynamic analysis tools. We decided that the diversity and depth of the tools available in the Dbux VSCode Extension might warrant the title of IDbE: Integrated Debugging Environment (not to be confused with IDE).

On Omniscient Debuggers

Back in 1997, in a heart-warming, informal call to arms, Henry Lieberman3 quotes skeptics saying: "Debugging is just plain hard" and "real programmers don't need debugging tools." Lieberman envisions a future where new innovative debugging tools (like his ZStep 954 omniscient LISP debugger) will surely become a staple of developer toolboxes around the world. 24 years later, the skeptics seem to have been proven right, and he wrong. While a lot of progress has been made in domain-specific debugging tools and automatic debugging research, general purpose code-level debuggers (or: the "traditional debugger") are still mostly the same as back then. We strongly agree with Lieberman that we are underutilizing the resources at our disposal. He argues, we should "use some of that speed and storage to process information that the programmer needs to understand what's going on in the program".

In some places, that idea has been put into practice: coverage reporting, for example, has become standard industry practice. It uses some of that "speed and storage" to record code execution metrics in order to help developers with an important aspect of automated testing. Another area of improvement is the wide range of browser tools that especially frontend developers enjoy; examples include the DOM inspector, the trusty network tab and many domain-specific tools that caring framework developers put in our hands, such as the React and Redux Developer tools5.

However, when it comes to general-purpose code-level analysis tools, little has changed over the past 30 years, which is rather odd. Imagine the manager of a large factory, running the factory based on observations from inputs and outputs, a "fax machine" and a "blueprint" alone. That is what is still happening in software development: debugging is still commonly performed by looking at what goes into and comes out of the blackbox that is the actual execution of our program, inspecting specialized logs (the "fax machine"), interleaved with reading and re-reading the code (the "blueprint"). To the Dbux team, this makes no sense. We are hoping that the 2020s shall finally be the time for the "next generation of debugging tools".

  1. Google: prefer print debugging.↩
  2. A notable exception is replay.io which adds recording, backward-navigation as well as collaborative debugging to the traditional debugger.↩
  3. Lieberman, Henry. "The debugging scandal and what to do about it." Communications of the ACM 40.4 (1997): 26-30.↩
  4. Lieberman, Henry, and Christopher Fry. "ZStep 95: A reversible, animated source code stepper." (1997).↩
  5. Redux Developer Tools. https://github.com/zalmoxisus/redux-devtools-extension↩