Intro, and Dogfood musings

Hi, my name is Steve Steiner. I work as a developer on the Visual Studio Debugger team. The debugger team has always been a bit of a strange and interesting place to work. For one thing, we get to dogfood the debugger as it is built.

Dogfood (verb) To use the software you are building. Derived from “eating your own dogfood.”

If you’ve never had to do it, the metaphor is very evocative of the actual practice. Dogfooding means we always have the latest features fresh from the daily drop. It also means the primary tool I use to do my job (the debugger) will break. I then get to stop what I’m doing and figure out why, and I get to use that broken tool to figure out why it’s broken. I’m not required to use the broken version. It’s perfectly acceptable to use a recent non-broken version to debug the broken one. Strangely enough however, it is often practical to do exactly what I said above when debugging on a machine that has only the broken version.

I tend to do that quite a bit now, as I own an integration suite. Owning an integration suite means you get to debug problems in other people’s code on other people’s machines. Debugging problems in code you don’t own is a very important skill. Doing so without the tools on your primary machine just adds an extra bit of annoyance.

Lest my grousing about other people's code leave you with the impression I never make mistakes, I’ll close with one of my own worst bugs added to the debugger. Circa 1996 I had just started in the VC++ team working on VC5. The problem I was trying to fix was with step over of recursive functions in the native debugger. I got the simple scenario I was looking at to work, and didn't fully understand the implications of what I did. The bug I added managed to cause a step over in the debugger to turn into a go if you were stepping over a call to alloca. I imagine you can guess the mistake. Yes I checked it into the tree and it was quickly caught and debugged by my dogfooding lead. Not a happy moment for me.