Prerequisites to Debugging

Before we get into the meat of debugging, I want to cover what you must know to be a good debugger. The first quality that all expert debuggers have in common is being good developers, too. You simply can't be a good debugger without being a good developer, and vice versa.

The Skill Set

Good debuggers and good developers all have strong problem-solving skills that are particular to software. Fortunately, you can learn and hone those skills. What sets great debuggers/developers apart from good debuggers/developers is that in addition to having basic problem-solving skills, great debuggers/developers understand how all the parts of a project relate to the project as a whole.

What you're building with the skill set is one of the most important debugging traits of all: intuition. The better your mental model of how things work, the faster you can start eliminating false leads and getting down to the real root issue of the problem. We've all worked with that one developer who just seems to know everything that's going on. I'll let you in on the secret: that developer doesn't, but he or she does know the logical progression of the key skill-set items and thus can get at the answer faster than you can.

The following list contains the areas in which you need to be proficient to become a greator at least a betterdebugger/developer:

• Your project

• Your language

• Your technology/tools

• Your operating system/environment

Know Your Project

Knowing your project is the first line of defense for user interface, logic, and performance bugs. By knowing how and where features are implemented in the various source files, you can quickly narrow down who is doing what to whom.

Unfortunately, because each project is different, the only way to learn your project is to read the design documents (if they exist), and to walk through the code in the debugger. If you have Visual Studio 2005 Team Edition for Software Architects or Visual Studio 2005 Team Suite, you can use the class diagramming tools to initiate that higher-level overview. It will never replace a solid model that shows data relationships between classes, but it will be more than enough to get you started.

One thing I've found very interesting in Wintellect's debugging business is how few companies have anything approaching design documents. As I described earlier in the Debugging War Story: Severe CFTL, we need to get that 15-minute overview from the Vice President of Circles and Arrows so we have an idea about the big picture. Invariably, the drawing will appear on the whiteboard and someone will exclaim in a loud voice, "Wow! I've never seen this before!" Immediately after that outburst, someone will run out of the room and grab a digital camera to start taking pictures of the first documentation he or she has ever had on the project.

If you don't have good documentation on the big picture of your project, get the senior developers to spend those 15 minutes to draw their version of the system. You can scan those drawings into Microsoft Office Word and drop them into your version control system. It's a cheap way to get at least the start of your application documented.

Know Your Language

Knowing the language (or languages) your project uses is more difficult than it sounds. I'm referring to knowing what your language is doing behind the scenes in addition to knowing how to program in it. For example, Microsoft Visual Basic developers have the very-easy-to-use On Error Goto construct for error handling. As that's how Visual Basic 6.0 did error handling; many Visual Basic developers are still using it. However, compared to structured exception handling in .NET, On Error Goto is a million times slower. In fact, On Error Goto should be renamed to On Error Goto Hell. We tracked down a performance problem in a client's application to the huge amount of code generated by a single On Error Goto statement being called in a loop. Many bugs, especially those that cause performance problems, are the result of language misuse, so it's well worth the effort to spend some time reading up on the idiosyncrasies of the programming languages you use.

Know Your Technology/Tools

Getting a handle on the technologies you're using is the first big step to tackling the more difficult bugs. For example, if you have an idea of what COM does to instantiate a COM object and return an interface, you'll have a much easier time tracking down why a specific interface request failed. The same goes for paying very close attention to something like your XML manipulation. The .NET Base Class Library (BCL) offers many ways of reading, writing, and manipulating XML data. As everything is XML-based these days, you need to have an idea of the differences as to why you'd want to use an XmlReader versus an XmlDocument class. I'm not saying that you need to quote files and lines from the source code or a book. Rather, I'm saying that you should have at least a general understanding of the technologies you're using and, more important, you should know exactly where you can find more detailed information if you need it.

In addition to knowing the technology, it's vital to know the tools you're using. A big portion of this book is spent discussing advanced usage of the debugger, but many other tools are out there, such as those distributed with the Platform SDK. The Visual Studio 2005 Team Editions come with more tools than some operating systems. You need to spend several days playing with the different windows in Visual Studio but also with open source and commercial tools. You never want to be in the situation of working on the showstopper bug from Hell and trying to learn the tools at the same time. A great deal of debugging is just having an idea of the capabilities of the tools because you can apply them faster to solve the problem.

Know Your Operating System/Environment

Knowing the basics of how your operating system or operating environment goes about doing its work can make the biggest difference between solving a bug and just floundering around. Every developer should be able to answer questions such as the following: What is a dynamic-link library (DLL)? How does an image loader work? How does the registry work? For managed code, you should know answers to questions such as: How does Microsoft ASP.NET find the components that a page is using? When do finalizers get called? What's the difference between an application domain and an assembly? Many of the worst bugs appear when you misuse the operating system or environment. My friend Matt Pietrek, who taught me a great deal about debugging, maintains that knowing the operating system/environment and the CPU is what separates the debugging gods from mere mortals.

Learning the Skill Set

With any job that regularly deals with technology, you have to study continually just to keep up, let alone get better and advance.

Besides reading books and magazines on debugging, you should also write utilities, any kind of utilities. The ultimate way to learn is by doing, and in this business, coding and debugging are what you need to do. Not only will you enhance your hard skills, such as coding and debugging, but if you treat these utilities as real projects (that is, by completing them on time and with high quality), you'll also enhance your soft skills, such as project planning and schedule estimating.

To give you some incentive to complete your utilities, consider this: completed utilities are excellent show-and-tell items to bring to job interviews. Although very few engineers bring their own code to demonstrate their skills to interviewers, companies consider those candidates who do well before those candidates who don't. Bringing a portfolio of the work you did on your own time at home shows that you can complete work independently and that you have a passion for software engineering, and it will almost immediately put you in the top 20 percent of engineers.

Another practice that has helped me a great deal, especially when it comes to learning more about languages, technologies, and the operating system, is to look at other engineers' code. As you probably know, a great deal of code that you can look at is floating around on the Internet. By running different programs under the debugger, you can see how someone else tackles bugs. If you're having trouble coming up with a utility you'd like to write, you can simply add a feature to one of the utilities you find.

Some of the most productive time you can spend with the Microsoft .NET Framework is simply looking through the Framework Class Library (FCL) source code. The great news is that even though we don't have that source code, we have the next best thing: Lutz Roeder's Reflector (http://www.aisto.com/roeder/dotnet). With a full decompiler and analysis tools to tell you who calls what, Reflector can teach you a tremendous amount of .NET development just by reading the Framework source code. Some of the most productive time I've ever spent has been just sitting around with Reflector asking myself how things work.

Reading books and magazines, writing utilities, reviewing other engineers' code, and doing reverse engineering are all great ways to improve your debugging skills. However, your greatest resources are your engineering friends and coworkers. Never be afraid to ask them how they did something or how something works; unless they are in the middle of a deadline crunch, they should be happy to help. I enjoy it when people ask me questions because I end up learning more than the individuals who ask the questions! Programming newsgroups are also excellent places to pose questions. I read them all the time because their responses are so good, especially from those folks Microsoft has designated MVPs (Most Valuable Professionals).