Debugging

If you are not a programmer by profession or interest (and most people aren’t) you probably don’t really know that debugging means. It is similar to correcting the grammar of someone else’s English report. Debugging tends to be dull, boring, frustrating and occasionally rewarding. Even though programmers would rather spend their time writing brand new, sparkling code, they end up spending the majority of it debugging.

Usually you debug a program because you want to fix a bug, “de-bug” it. The story goes that in one of the first computers a moth was found jamming a switch. So the first debugging session removed an actual bug.

In order to fix a bug you must be able to reproduce it. If you can’t see the error, you can’t fix it. This can be very frustrating. Users, often called “losers” by programmers, can’t really describe the problem they had, but they want it fixed. Sometimes a programmer will tell the user the problem is fixed even though it isn’t, because the probability of the same problem occurring is miniscule.

I do debug MTG Forge from time to time. Usually I want to be adding cards from the latest set, but I try to fix any important bugs. I just fixed an error when you use the “resizable game area” option and the computer blocks with multiple creatures. A separate window should popup but instead there was an error message. Thankfully it showed me the exact line that I needed to fix.

I made an assumption that the game area would always be this one specific class, GuiDisplay2, but since I added another class, GuiDisplay3, the assumption was incorrect. Debugging corrects faulty or outdated assumptions as well as errors in logic. Thankfully this error was easy enough to reproduce and fix, and only took about 15 minutes of time. May all errors be this easy ;-)