Chapter 1: Strategic Debugging Issues

Overview

Backina former existence as a professional chess player, I learned to differentiate between the strategic and the tactical understanding of a chess position. The strategic understanding involved appreciating the ideas and plans that underlie a chess position, whereas the tactical understanding concerned the actual implementation of these plans. In chess, these two elements have to be blended together. Strategy without tactics is mere posturing. Tactics without strategy is usually motion without progress.

When I moved into programming computers, I was surprised to find that most debugging books seem to concentrate only on the tactics of debugging. They often go directly into debugger usage and heavy debugging, and mainly discount the strategic ideas. These books tend to ignore the fact that all bugs aren't alike and that different classes of bugs have different reasons for their existence. They rarely investigate why bugs happen.

This chapter looks at strategic application design issues in the .NET world. Without a good understanding of these issues, all the heroic debugging in the world is not going to help you. The principle here, and a thread running through this book, is that bug prevention is much more valuable than bug finding and fixing. No matter how deftly you can wield a debugger, without understanding these issues you'll find that you're building your applications on quicksand. You may still be able to build a wonderful castle, but its brittle foundations will cause bugs that can only be fixed through a significant reengineering of the core of your application.

Later chapters go into much more detail on the tactics of bug prevention and debugging, but here I want to look at the bigger picture. While you might find it tempting to jump straight to Chapter 2 for some interesting code or to Chapter 3 for an in-depth introduction to the Visual Studio (VS) .NET debugger, please resist the temptation . The big picture presented in this chapter is invaluable for making software-quality decisions and for understanding the best methods of preventing bugs.

Visual Basic (VB) .NET will certainly be used to build a larger set of applications than is feasible with VB.Classic. These applications will typically be bigger, more complex, more distributed, and often accessed by a larger user base. The issue from a debugging point of view is that designing for application reliability becomes much messier as an application scales up in size and complexity. As your end-user customer base becomes larger and demands ever more from the applications that you write, you need to take a serious look at your design processes to ensure that bugs don't grow in proportion with your systems.

This chapter investigates two core design issues when working with VB .NET: reliability and availability. It looks at what you need to understand in order to build systems that are both reliable and highly available to your end users. Because this is a book about software, I only take a brief look at the related hardware issues. Bear in mind, though, that hardware issues may well affect how you design your software. It's often necessary to change the design of your software in order to fix problems or errors that are hardware related .