Introduction


Bugs suck. Period. Bugs are the reason you're subjected to death-march projects with missed deadlines, late nights, and grouchy coworkers. Bugs can truly make your life miserable because if enough of them creep into your software, customers might 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 the first edition of this book, NASA lost a Mars space probe because of a bug that snuck in during the requirements and design phase. While I was writing this edition, a bomb was dropped on American Special Forces soldiers instead of the intended target because batteries were changed in GPS software, causing a programming error. With computers controlling more and more mission-critical systems, medical devices, and super expensive 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're 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 .NET and 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 code with 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 the practices in this book will help you to limit the number of bugs you add to your code and to track down more quickly those inadvertent bugs that do occur.

The second issue is that though many excellent books on specific .NET and 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 ASP.NET control that plugs into your ASP.NET page, but it's another thing entirely to be able to debug that ASP.NET control. To debug that ASP.NET control, you'll have to know the ins and outs of .NET and ASP.NET, how DLLs get put in the ASP.NET cache, and how ASP.NET goes about finding those controls in the first place. Some books make it look easy to implement sophisticated features, such as remote database connections, by using the hot technology du jour, but when "db.Connect ("Foo")" fails in your program—and it eventually will—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 on 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 corrupted database or 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 and as a consultant trying to help others ship 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 .NET as well as the native 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 eight years. A few experiences have helped shape my unique perspective on the subject of debugging. The first experience was at NuMega Technologies (now Compuware), where I was one of the first engineers working on cool projects such as BoundsChecker, TrueTime, TrueCoverage, and SoftICE. While working at NuMega, I started writing the "Bugslayer" column in MSDN Magazine, and then I eventually left to write the first edition of this book. The fantastic e-mail exchanges and interaction I've had with engineers developing every type of application imaginable teaches me even more about the issues that engineers face today when shipping products.

Finally, the most important experience of all in shaping my view has been forming Wintellect, which gives me the chance to go out and help solve those amazing problems for companies all over the world. Imagine that you're sitting in some office at 2 a.m., you're out of ideas, and the client's going to go out of business if you don't solve the bug—this scenario can be scary, but it also gets your adrenaline flowing. Working with the best engineers at such companies as Microsoft, eBay, Intuit, and many others is the best way I know to learn all sorts of great tricks and techniques for solving bugs.

Who Should Read This Book?

I wrote this book for developers who are tired of spending late nights at work debugging and want to improve the quality of their code and their organizations. I also wrote this book for managers and team leaders who want to develop more efficient and effective teams.

From a technical perspective, the "ideal reader" is someone who has one to three years of experience developing on the .NET or Windows platform. I also expect the reader to have been a member of a real-world development team and to have shipped at least one product. Although I don't care for the term, the software industry labels developers with this level of experience "intermediate developers."

Advanced developers will probably learn a great deal as well. Many of the most enthusiastic e-mail messages I received about the first edition were from advanced developers who didn't expect to learn anything. I was thrilled that the book was able to give them tools they could add to their toolboxes. Again, as in the first edition, a wonderful group of friends named the "Review Crew" reviewed and critiqued the chapters before I submitted them to Microsoft Press. These engineers, who are listed in the Acknowledgments section of this book, are the cr me de la cr me of developers, and they made sure that everyone reading the book would learn something.




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

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