The History of Debugging: Part 1

Reading Time: 3 minutes

Disclaimer: there might never be a Part 2.

Together with Maarten (who already has written some content concerning debugging and monitoring software), we’re going to write some posts about the concept of debugging code. And to introduce the topic, why not start with a little bit of (mostly personal) history on the matter?

ENIAC

It’s hard to imagine nowadays, but writing software wasn’t always literally writing: on the ENIAC i.e., the programmers had to make physical connections between the different components, replacing burnt out vacuum tubes as they progressed. They did actually write the program on paper first though, and did their very best to run through it step by step before starting to program the actual computer. And even then, they went through the program again: even the ENIAC already supported step-through debugging!

ENIAC

My First Program and QBASIC

When I was in the Sixth grade, at the age of eleven, I got the chance to learn to program in QBASIC on a 386 PC, running MS-DOS 6.0, during breaks. Well, that and the occasional Sega OutRun game.
But programming really caught my interest and I quickly went through the assignments my teacher had created. Meanwhile, we got a PC at home, so I could continue learning to program. In the end, I’d written several game clones like Breakout, Tetris, etc.

My programming skills, however, were quite limited: it took me a while to figure out that I could use subroutines (GOSUB) instead of line numbers and the now dreaded GOTO. And as far as debugging was concerned, I was using the oldest trick in the book: a lot of PRINT statements to know the value of certain variables at specific steps in the code. I’m not kidding when I say that I only recently found out that QBASIC supported step-through debugging and setting breakpoints in code: nobody told me these things when I started programming and I didn’t know English well enough to figure this out myself.

Moral of the story so far: you will learn to appreciate any help the debugger tools provide once you had to resort to printing variable values.

Windows 3.11 and Visual Basic 4.0

As I got older, I stumbled upon VB4 which allowed me to create software with Forms. My own Windows in Windows! And because I started getting English class at school, I also understood more about the options I had to create software. Finally I discovered things like breakpointswatchesstep-through debugging and Visual Basics way of error handling. Aside from games, I could also start writing more useful software for family and friends.
The summum? Writing a new UI which emulated the Windows 95 look and feel to convince my dad to upgrade the PC (it needed 8 megs of RAM instead of 4) and to buy that shiny Windows 95 upgrade.

VB6, C/C++, PHP, …

I also upgraded to Visual Basic 97, then 6.0, started to dabble in C/C++ and wrote my first web applications in PHP. That was a step back in time really. Sure, you could run a WAMP server locally to test your code, but you couldn’t attach a debugger to that server to debug the code as you went through the application (I’m talking about PHP3/4 here, way before the Zend era). So instead, I had to rely on echoing stuff back into my web pages or logging it and looking at the log files. Or even worse, stop the code from processing at all using die() statements, which typically happened when you couldn’t connect to the MySQL database.

Maybe we are spoiled today, with the capabilities offered by the different debugger tools available. But then again, are we using them efficiently? Find out in my next post in this series!