
 |
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.

