The Science of Debugging
Chapter 1.1


Chapter 1 - The Science of Debugging


Contents:
1.1 What is Debugging?
1.2 How do I Debug a Program?

1.1 What is Debugging?

"Debugging is a science. You formulate a hypothesis, make predictions based on the hypothesis, run the program and provide it experimental input, observe its behavior, and confirm or refute the hypothesis." - Michael Chastain, "The Art of Debugging"

Debugging is a fairly complex science, and our definition of it is going to be quite a bit broader than that above. For our purposes, debugging is the use of any process, utility, system, software, or management of computer code which can locate or remove faults in the code, or reduces the chances of faults being introduced in the first place. I make this statment not just because it is impressive sounding, but to make a serious point. Debugging is not just program modification, but also includes such aspects such as project planning, and source code revisioning.

In short, anything you do to quash a bug is debugging - even if the bug doesn't exist yet!

For our purposes, the 'ideal' debugging cycle for a project is going to look like this:



To break this down for you a bit more;

The Concept of the Project

The concept is your overall idea. Is this going to be a Quake-like game, or a spreadsheet application? Are you more concerned with utility, speed, entertainment, historical accuracy, or a physical model representation? For a game, one of the top priorities is you need to determine is your player market; is the game going to sacrifice broad-spectrum entertainment for challenge, or player-versus-player scenarios? Are you trying to get the most players, or build a loyal base? Make sure to spend time on this, and WRITE IT DOWN®. You're going to see that phrase alot throughout the planning sections of this book. Nothing stops miscommunication more easily than having a written copy.

Project Plan

A project plan is a set of specific requirements regarding a given idea. You may be adding your idea, or modifying or removing an old one. Regardless of which you pick, you'll need to draw up a detailed description of the change you wish to put in place. A good check to throw in here is whether or not your completed project plan adds anything to the values you set up in the Concept phase. If you generate a realistic physics model, and it doesn't provide added value to your priority items (maybe user interface?) or worse, conflicts with them, you probably shouldn't have added it in the first place!

Writing Code

Writing code is the easy part. This also includes fixing compile-time errors (aka, syntax errors. aka not-really-an-error). In fact, this may also include things like making changes to data files, populating databases, or the sort.

Source Errors

As the above is the easy part, this is the hard part. Using various methods; from logging, to using a debugger, even simple trial-and-error experiementation and automated stress testing. Someone once said "Every computer program has at least one bug." Many people believe this is the only sort of debugging there is. Those people are wrong.

Fix Code

.... If I have to explain this, you may be reading the wrong guide ....

Check In Code

It's time to finalize your changes - copy your beta files over to the production system, unlock your files in your source code repository and perform any conversions required. This can be a simple process, or a complex one, depending on how well you've designed your code (to allow for modifications), and how much impact your change has.



Index
Contents of Book 1.2 How do I debug?