Introduction

[Previous] [Next]

Bugs suck. Period. Bugs are the reason you endure death-march projects with missed deadlines, late nights, and grouchy coworkers. Bugs can truly make your life miserable because if enough of them creep in to your software, customers will stop using your product and you could lose your job. Bugs are serious business.

Many times, people in our industry portray bugs simply as annoyances. Nothing could be further from the truth. All engineers can point to projects with runaway bug counts and even to companies that have folded because they released software so full of bugs that the product was unusable. As I was writing this book, NASA lost a Mars space probe because of a bug that snuck in during the requirements and design phase. With computers controlling more and more mission-critical systems, medical devices, and superexpensive hardware, bugs can no longer be laughed at or viewed as something that just happens as a part of development.

My hope is that the information in this book will help you learn how to write your applications with fewer bugs in the first place—and that when you are required to debug, you can do it much faster. Without realizing it, most teams spend an average of 50 percent of their development cycle debugging. If you start debugging properly, you can drastically reduce that amount of time, which means you'll ship your products faster. You can't cut corners when it comes to requirements gathering and design, but you can certainly learn to debug much smarter. This 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. I believe you need to start debugging in the requirements phase and continue through to the final release to manufacturing.

Two issues make debugging in the Microsoft Windows environment difficult and time consuming. The first issue is that debugging has always been a self-taught skill—you've basically been on your own to figure it out. Even if you have a computer science degree, I'm willing to bet that you never took a single college class dedicated to debugging. Other than some esoteric subjects, such as devising automatic program verification for languages that no one uses or developing debuggers for wildly optimistic, massively parallel-processing computers, the science of debugging as it applies to commercial software doesn't seem to be popular with the educational establishment. Some professors point out that you shouldn't be writing bugs in the first place. Although that's an excellent point and an ideal we should all strive for, reality is a little different. Learning systematic, proven techniques for debugging won't save you from ever writing another bug, but following these practices will help you to limit the number of bugs you add to your code and to track down those inadvertent bugs that do occur more quickly.

The second issue is that though many excellent books on specific Windows technologies are available, none of them cover debugging those technologies in enough depth to be useful. To debug any technology effectively, you have to know far more than a book focused on a specific technology provides. It's one thing to know how to write an ActiveX control to plug into Microsoft Internet Explorer—and another thing entirely to be able to debug that ActiveX control. To debug an ActiveX control, you have to know the ins and outs of ActiveX and the Component Object Model (COM), how dynamic-link libraries (DLLs) map into memory, and how COM goes about finding and creating controls. Some books make it look easy to implement sophisticated features, such as remote database connections, using the hot technology du jour, but when "db.Connect ("Foo")" fails in your Visual Basic program—and it always does—you're on your own to find and mend the broken link in the technology chain. Moreover, although a few books on project management do discuss debugging, they tend to focus on managerial and administrative issues rather than developers' concerns. Those books might include fine information about how to plan for debugging, but they don't help much when you're staring at a crash returning from a callback function.

The idea for this book came out of my trials and tribulations as a developer and manager trying to ship high-quality products on time. Over the years, I've learned skills and techniques that I use to deal with each of the two issues that help make developing Windows-based applications a challenge. To address the first issue, the lack of formal debugging training, I wrote the first part of this book to give you a crash course in debugging—with a decided slant toward commercial development. As for the second issue, the need for a book specifically on debugging in the Windows environment, I think I've provided a book that bridges the gap between specific technologies and nitty-gritty, real-world debugging techniques.

I've been extremely fortunate to have had the opportunity to focus on debugging almost exclusively for the last five years. A couple of experiences have helped shape my unique perspective on the subject of debugging. The first experience was at NuMega Technologies (now Compuware NuMega), where I was one of the earliest engineers. There I was privileged to work on great teams writing automatic error-detection tools (BoundsChecker), performance tools (TrueTime), code-coverage tools (TrueCoverage), and debuggers (SoftICE). Working on products whose customers (you!) scream bloody murder when they find a problem "encourages" you to write and ship the best products possible.

In addition to having worked as a software engineer and manager at NuMega, I have the pleasure of writing the "Bugslayer" column in Microsoft Systems Journal. In the column, I focus on debugging, and my constant interaction with engineers developing every type of application imaginable teaches me even more about the issues that engineers face today when shipping products.



Debugging Applications
Debugging Applications for MicrosoftВ® .NET and Microsoft WindowsВ® (Pro-Developer)
ISBN: 0735615365
EAN: 2147483647
Year: 2000
Pages: 122
Authors: John Robbins

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net