Slow Dancing With Technology: Debugging, the Programmer and the Machine

Anyone who has worked on coding even the most basic projects knows that the process requires a good bit of patience. The numerous pitfalls of trying to write code from scratch are a song and dance of all the many ways a human programmer or developer can get it wrong. It’s a long list, and it includes everything from syntax errors, which will usually get caught by the compiler, to deeper “vision-level” bugs that require more intelligent review. To that end, schools and training centers teach computer science students how to “debug” a program. What’s interesting, however, is that every individual develops his or her own very unique response to this challenge. In fact, this may be an area where more than a little personal insight is required. (Read about some of programming’s most important figures in The Pioneers of Computer Programming.)

Debugging Code: How It’s Done

In 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 Bugs

The 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 IT 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.” (To learn about the history of programming, check out Computer Programming: From Machine Language to Artificial Intelligence.)

Why Bugs Evade Capture

One 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 Debugging

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