Debugging Code: How It's DoneIn some cases, computer science professionals are able to use resources from developer studios or programming environments to isolate bugs in a program. When these sorts of error handling or system messages aren’t available or useful, though, debugging requires going through code line by line. Many programming environments, such as the Microsoft Visual Basic Studio, have features that allow clear, visual line by line "stepping" through code.
Stepping through code helps in two main ways: first, programmers can see what is happening as the computer reads the code, and where the focus goes in terms of recursive functions and other code interactions. Secondly, though, the programmer can often see the values of different variables by using mouse-over commands or other parts of the interface. Knowing what values are in variables is a key way to understand what the computer is doing with the code that it is given.
Battling BugsThe process described above may sound simple, but the actual challenge of debugging can be a lot more complicated. An excellent example of this process at work can be found in the tech-thriller aptly titled "The Bug" by Ellen Ullman, a former developer and I.T. professional whose prose shines in a literary way. Although the book is fiction, it reveals a lot about what’s actually going on when programmers and computers interact.
Leaving aside a lot of the darkly personal detail in the book, Ullman’s portrayal of two people, a tester and a programmer, shows some of the major challenges these career techies faced in the earlier era of software development. Basically, her bug, which she calls "The Jester," eluded everyone at a 1980s software company, straining employee relations, collapsing investor confidence, and generally causing a ruckus. Meanwhile, the author reflects quite a bit on how computers affect us, and why, if we want to triumph over their idiosyncrasies, we have to "think like a machine."
Why Bugs Evade CaptureOne reason that the bug in Ullman’s book was so hard to deal with is that it only popped up at odd times. This challenge really rings true for many other such glitches (just remember Toyota’s extensive trials after user rumors of a runaway Prius). Suppose that someone tells you that you have a bug. Unless you can make the computer manifest a problem, where do you even start in terms of fixing it?
The reason for this glitchiness, as revealed at the book’s end, is another great example of the complexities of writing code for the personal computer in that era - and perhaps still in ours. Essentially, the the bug was hidden in a small, nested function that simply provided a basic orientation to other pieces of code. Because it was written by a third-party programmer, and because of a lack of communication between programmers, the true source of the problem remained hidden for months - a true testament to the problems can arise from improperly documented teamwork.
When it comes to a computer bug, a tricky detail can throw an otherwise ordered system into chaos. Good coding skills, therefore may sometimes be more art than science (Ullman calls it "madness"), making coding an inherently messy business.
The Philosophy of DebuggingProgrammers often have to work with computers - not people - to achieve results. Ullman suggests that coders and testers are often most effective when they are able to put away all of the nuances of human thought and strip reasoning down to the base logic computers use. This means setting aside a lot of what we all come to work with every day to obtain a clarity of focus. It’s this quality that allows many top computer science pros to thrive, even in an age when a lot more of a framework has been put in place for most projects.
Thoughtful leaders have dreamed up a more fluid software release structure to bridge the development and production environments, but computer programming still has an element of sorcery to it. That's why the best programmers are more than just structural coders; they have the instinct to root out and fix the bugs that threaten the functionality of the machines upon which we increasingly rely. (Read about the history of programming in The Pioneers of Computer Programming.)