View RSS Feed

//no comment


Rate this Entry
Most programmers will say that debugging is their least favorite part of programming, although the exact reason may vary. I believe that debugging is at the core of programming. The thought process involved in systematically and efficiently walking through an issue until a solution is found is a skill which programmers are never finished developing. My view is that the only way to get better at debugging is to do it; a lot.

The debugging practice I've gotten from TSM has improved my overall programming skills more than anything other part of TSM (or any project I've worked on for that matter). While I could give an endless list of TSM examples, I'm going to give an example for another project of mine I was working on today. This particular example is relatively trivial, but is a good example of the process of debugging. Sorry in advanced if this is too technical or goes over your head.

First, some brief background information. The project (well, the small sub-section of the project) I was working requires a desktop application to send text data to a microcontroller board over Bluetooth to be displayed on big display. I had first connected everything up with a USB cable instead of Bluetooth since I knew my USB cable setup worked. Once I confirmed everything worked as intended, I replaced the USB cable with a Bluetooth board connected to the microcontroller and the Bluetooth which is built into my laptop didn't work. I could tell I was making a Bluetooth connection thanks to some LED indicators on the board, but the microcontroller was not getting any data I was sending it. Bummer.

Having worked with this type of Bluetooth communication in the past, I knew that the problem was probably one of mismatching baud rates (baud rate is how fast the data is being transferred, in bits/second and must be consistent at all points for the data to actually make it from point A to point B). There's 3 different places that I knew of that the baud rate had be set, and they all had to match: the desktop programming running on my laptop, the Bluetooth board connected to the microcontroller, and the actual microcontroller itself. The first step was to check the desktop program's baud rate which was as simple as adding a print statement to the code. It was 9600. Finding the baud rate of the microcontroller was even easier, it was manually entered right into the code; also 9600. It must have been a problem with the Bluetooth board.

Determining the baud rate of the Bluetooth board is where it gets tricky. Viewing/changing the baud rate requires knowing what the baud rate is (fun isn't it?) and then hooking up a configuration board. Fortunately, there are only 20 or so possible baud rates, and an even lower number of baud rates I personally would have set it to (I am the one who set it originally). Trial and error eventually found the baud rate was 57600. I changed the desktop application and the microcontroller to 57600 (preferred value to 9600 and it was easier than changing the Bluetooth chip to 9600) and everything worked perfectly. Success! Of course, this was 30 minutes later.

This time spent debugging didn't involve any design work or actual improvement to the code (other than it working vs not working), but is a required part of the programming process. Debugging is an excellent example of not making the same mistake twice. My prior experience with this Bluetooth board (and this type of communication in general) meant I knew exactly what was wrong without too much though. However, as is often the case, knowing what sort of problem is occurring (ie mismatched baud rates) is only half the process, but this half can be reduced to near-zero time with practice and experience.

Having spent much more time in the past on similar issues to obtain this knowledge, I've learned a great deal about working with this hardware. Similarly, I've learned a ton about WoW addon development by wading through the seemingly endless supply of bugs users find in TSM. As such, I believe debugging is one of the most important part of programming, even if it's not the most enjoyable.

PS: The most miserable debugging experience I can remember stemmed from somebody inadvertently mixing two values of a component in a bin which resulted in very subtly (but critically) incorrect behavior. Spent a good weekend on this one.


  1. Stede's Avatar
    You're not a serious programmer until you've a debugging story that you can tell at the bar. While I've a few, the more recent ones have to do with SAS, and that's a language that works differently from most others. But the one I always tell is about my first C++ course that I took in college. We were using the Borland C++ DOS-based compiler for the class, and I had written my simple little program with the necessary idiot-proofing to handle user entry errors, but I kept getting a compiler error.

    I stared and stared at the screen - for hours. This thing was due the next day. I thought it would be easy enough to knock out in just 30 minutes, but everything I tried just wasn't working. I decided to trash the program and write it again - and I still had problems! I tweaked and twerked this and that for another hour, and was ready to give up. As a last effort, I rewrote the program again - I couldn't understand why the compiler was hanging on the solitary loop that I'd written.

    And that did the trick. As the realization of what went wrong hit me, I sat slack-jawed staring at the screen. After writing so many papers for my other classes, I was capitalizing the 'w' in the While statement. But in the DOS-based compiler, both 'w' and 'W' displayed identically on the screen. What.... the...

    Looking back on it, it was one of the more docile errors I've encountered. Runtime errors, and those that are buried within logs running 100s of pages within various layers of macros, subroutines, and custom function calls prove themselves quite challenging. Having a background in Math has been a great help, though - especially all the years I spent tutoring folks. It was a daily thing that someone would ask for help - showing me the answer in the back of their book, and their pecil and paper work so far with a perplexed look on their face, "I have no idea how they got this..." After 20 seconds or so, if I couldn't trace their mistake, the obvious answer was usually, "Did you write the problem down correctly." Four out of 5 times - No.
  2. twitchietgw's Avatar
    My most frustrating debugging experiences are in dealing with proprietary software, where you *could* fix it if given enough time and the opportunity, but you aren't allowed. So you have to develop whacky systems with configuration, sneaky programs or just play post cluster $#@% database clean up.

    My favourite of these, while working on an open architecture clinical information system was the message (from hospital feeder systems) processing components inability to deal with daylight savings in non-US timezones. Each year, it would reject a full hour worth of messages because... when the clocks go forward in the US, that time doesn't exist. We reported the issue, and had the obligatory wee hours of the morning conference call with the vendor's (very lean) support team. Nada. We just started playing weird games with our test system which we could restart at will (99.8% availability on production doesn't give you that kind of flexibility). Finally, the solution was to just put garbage into the unix boxes configuration for timezone, and all the messages could be processed. Some calls out to hospitals, and we could get a couple of restarts organised (just on the message processing side) and bam! solved...

    … for one year. We kept hammering the vendor as much as we were allowed, and more than 18 months later we had a patch. Woo hoo!