The Barnes & Noble Review
Debugging: it's the aspect of development most likely to keep you up all night, screaming at your computerand your colleagues. What's worse, when you think about your development cycle, it's not unusual for debugging and related activities to eat up half your time. If you develop for Windows, there's a new alternative to more coffee and Jolt Cola: Debugging Applications, by John Robbins.
Robbins writes the Bugslayer column for Microsoft Systems Journal, and you won't find a more dedicated, committed expert on the subject. As he puts it, his new book takes a holistic approach to debugging. "I don't consider debugging as a separate step but as an integral part of the entire product cycle... you need to start debugging in the requirements phase and continue through to the final release to manufacturing." That's what this book shows you how to do.
Robbins starts by presenting "the gestalt of debugging"defining the different types of bugs that exist, and presenting an approach and process to debugging that many great developers have evolved on their own. Robbins also offers specific, Windows-focused techniques for proactively debugging as you write your codeand for keeping you out of your debugger by helping you write cleaner, less buggy code up-front.
Next, he introduces "power debugging" techniques that make the most of your debuggerwhichever one you're using, in Visual C++ or Visual Basic. Most developers don't use a fraction of the power of their debuggersafter youreadRobbins, you won't be one of them.
In Part IIIfully half of the bookRobbins presents solutions to the debugging problems you're most likely to encounter in Windows applicationsfrom tracking down deadlocks in multithreaded programs to automatically testing user interfaces, debugging Windows 2000 services and DLLs that load into services, and more. Throughout the book, you'll also find great sidebars and war storiesmany from his experience at NuMega, one of the world's leading providers of debugging tools. Once you read this book, you'll never look at debugging the same way againand you certainly won't spend as much time doing it!
Read an Excerpt
Chapter 2. Getting Started DebuggingIn this chapter, I'll introduce some important infrastructure tools and requirements that will contribute to your debugging success over the lifetime of your application. Some of the tools involve the engineering process, and others are software utilities. What they all have in common is that they allow you to see the progress of your project on a daily basis. I believe this daily monitoring is the key to getting your product out the door on time-with quality. Projects don't slip massively in one day; they slip a little each day along the way.
All the ideas presented here and in Chapter 3 come from my experience shipping real-world software products, and I can't imagine developing without these tools and techniques. I've learned some lessons the hard way, and I hope to save you time and pain by sharing with you what these lessons have taught me. You might think that some of these ideas don't apply to you because you're on a two-person or threeperson team. Don't worry, they do. Even when I'm on a team of one, I still approach a project in the same way. I've worked on projects of every size you can think of, so I know the recommendations I make scale from the tiniest to the largest teams.
Track Changes Until You Throw Away The Project
Version control and bug tracking systems are two of the most important infrastructure tools you have because they give you the history of your project. Although the developers might say they can keep everything in their heads, the company needs to have some record of what's been accomplished on the project in case the entire development team wins the lottery and everyone quits the next day. Because most teams don't adequately maintain their requirements and design documents throughout the life of a project, the only real documentation becomes the audit trail in the version control and bug tracking systems.
I hope I'm preaching to the converted. Unfortunately, I keep running into teams that haven't yet started using these tools. As someone interested in history, I feel you have to know where you've been to know where you're going. Putting these two tools to use is the only sure way to learn that lesson. By monitoring the outstanding bugs and bug fix rates in the bug tracking system, you can better predict when your product will be ready to ship. With the version control system, you'll get an idea of your "code churn," the volume of changes, so that you can see how much additional testing needs to be done. Additionally, these tools are the only effective way to judge whether you're getting any results from changes you implement in your development cycle.
When you bring a new developer to your team, these tools can pay for themselves in a single day. When the new developer starts, have her sit down with the version control and bug tracking software and begin working her way through the changes. Good design documents are ideal, but if they aren't available, the version control and bug tracking systems at least provide a record of the code evolution and highlight any trouble areas.
I'm talking about these two tools in the same breath because they are inseparable. The bug tracking system captures all the events that might have driven changes to your master sources. The version control system captures every change. Ideally, you want to maintain the relationship between reported problems and actual changes in the master sources. By correlating the relationship, you can see your cause and effect for bug fixes. If you don't track the relationship, you're left wondering why certain changes to the code occurred. Invariably, in later versions of the product, you have to find the developer who made the change and hope he or she remembers the reason for the change.
Some products are integrated and automatically track the relationship of the master source change to the bug report, but if your current systems don't, you'll need to maintain the relationship manually. You can track the relationship by including the bug number in the comments that describe the fix. When you check the file back into version control, you'll need to identify the bug number you're fixing in the checkin comment for the file.
Version Control Systems
The version control system isn't just for your project's master sources. Anything and everything related to the project-including all test plans, automated tests, the help system, and design documents-needs to go into the version control system. Some companies even include the build tools (that is, the compiler, linker, include files, and libraries), which allows them to completely re-create the shipped version of their product. If you have any question about whether something should go in version control, ask yourself whether maintenance programmers could use the information in a couple of years. If you think they could, that information belongs in the version control system.
Tracking change is vital; however, having a good bug tracking system in place doesn't mean that developers should be allowed to make wholesale changes to the master sources whenever they want. Such carte blanche would make all the tracking pointless. The idea is to control the changes during development, restricting certain types of changes to certain stages of the project so that you can have an idea of the state of the master sources on a day-to-day basis. The best scheme I've heard of for controlling changes comes from my friend Steve Munyan, and he calls it "Green, Yellow, and Red Times." In Green Time, anyone can check in anything to the master sources. The earliest parts of the project are usually fully in Green Time because at this point the team is working on new features.
Yellow Time is when the product is in a bug fix phase or nearing a code freeze. The only code changes allowed are for bug fixes-and only bug fixes. No near features or other changes are permitted. Before a developer can check in a bug fix, a technical lead or a development manager must approve it. The developer making the bug fix must describe the bug fix he's making and what it affects. In essence, this process is a mini code review for every single bug fix. On some teams I've been on, the product was in Yellow Time from day one because the team liked the code review aspects of this stage. We did loosen the approval requirements so that any other developer could approve changes. The interesting outcome was that because of the constant code reviews the developers caught many bugs before they checked the code into the master sources.
Red Time occurs when you're in a code freeze or near a key milestone and all code changes require the product manager's approval. When I was a product manager, I even went to the extent of changing the permissions in the version control system so that the team had read-only access. I took this step mainly because I understood what the developers were thinking. "This is just a little change; it will fix this bug, and it won't hurt anything else." The developers' intentions were good, but that one little change could mean that the entire team would have to restart the test plan from the beginning.
The product manager must strictly enforce Red Time. If the product has a reproducible crash or data corruption, the decision to make the change is essentially...