Over the past couple of years the debugger team invested heavily in understanding how our different user groups debug, and use the debugger. It turns out that debugging and using the debugger is not the same thing because a significant number of our users do not use the debugger much, if at all. Here I am going to talk about the debugger, and how the debugger team leveraged the user data to design features to make the debugger more powerful and more efficient. This goes back to the early days of Visual C## Whidbey planning, and talks about how some of the research is manifesting itself in the Whidbey debugger. While many of these observations and a lot of this work are relevant to all Visual Studio developers, this focus of this work is on C# developers.

Starting Point: Observing Users

Early in Whidbey, we kicked off our studies of Visual C# usage with a fairly large study focused on application writing in general. We made up four programs for users to write, covering a wide range of possible tasks in Visual C#. We recruited 29 C# users, and had each user spend about 2 hours trying to write one of the programs. By watching the users work, we were able to get an idea across the users how they work, and what usability problems they encountered with Visual C#.

We also visited a number of Microsoft developers using Visual C#, as well as a number of external users. On these visits we watched users program for a couple of hours to see how users are using Visual C# in the real world. After spending all of this time watching users, we had enough information to start drawing some basic conclusions about C# users and Visual C#. Since then study, we’ve run numerous usability studies that focused directly on the debugger, and we’ve also observed a lot of debugger usage in other studies as well. In all of these studies we’ve seen our basic understanding validated over and over again.

The Recurring Pattern of Behavior: Trigger, Set, Step, Inspect

We observed three types of events, or “triggers” that cause users to start using the debugger:

  1. New Code Trigger happened when a user just wrote new code, and wanted to step through it through the debugger to make sure that the code worked the way they expected.
  2. The Code Flaw Trigger happened when a user’s code did not work as they expected, for instance if there was a bug in their code.
  3. The Exploration Trigger happened when users wanted to find out how something worked. For instance, if they were given some code and wanted to know how it worked they would step through it in the debugger. Some users would also use the debugger to see how a class in the Framework worked. For instance they would create an instance of the class and then break on it.

Regardless of the trigger, it turns out that users do the same basic thing with the debugger. We haven’t done much to see how the different triggers impact debugger usage, which may be a task for the next version. Anyway, after the users decided to use the debugger, they would set a breakpoint in their code, normally by clicking on the column for breakpoints with their mouse, run the code, and then step through the code line by line as they watched the values of variables in their code change. We called this “Trigger, Set, Step, and Inspect”, the basic debugger work model.

 

Trigger

->

Set

->

Step

->

Insepct

We then used this model by projecting usability problems onto it, and seeing where the bottlenecks were for users. We also noticed that they spent most of their time in the “inspect” block.

Users’ first choice for inspecting values seemed to be by using the hover over value by pointing at a variable name with the mouse. Other common approaches were to use the watch window or the quick watch window.

In my next entry I'll talk about some of the common usability problems C# users encounter with the debugger, and some of the work done to address those problems.