BREAKPOINTS

Test, Debug, Release, Rinse, Repeat ...

September 2006

Here's something that happens to me fairly frequently, and I'm continually amazed that this works.

The other day I was building the Template Toolkit Perl module via CPAN. Anyone who has done this will recognize a snippet of the output of the test harness that all CPAN modules use:

t/factory.............ok
t/file................ok
t/fileline............ok
t/filter..............ok

only, in my case the "t/fileline" entry was most definitely NOT ok. It spewed out an error that made absolutely no sense to me. Something about template output not matching what was expected.

That's not the interesting thing: errors while building Perl modules happen all the time. What I find interesting is what I have found to be the most expedient way to fix this when it happens: I just Google the error message. in 60 seconds I had found the fix, pasted the new lines into the test file, and was rebuilding the module with no errors.

This isn't the most intellectual form of debugging, obviously. It entailed precisely zero real understanding of the problem on my part. I was just functioning as a patch-retrieval machine in this process. I suppose it can be argued that this is a bad thing, but let's face it: There are times when you just don't care why it's broken. You only want it fixed, and fixed now so you can move on. At times like that, I thank my stars that I can Google debug.

Posted by Kevin Carlson at 12:22 PM  Permalink |

GUI code bottlenecks can wreak havoc with an application's usability. UI responsiveness is definitely something that you should be testing, because it can make a structurally sound app look like junk, and can kill not only the users' perception of the app's quality, but can actually make them less productive. Fear not: Joe Duffy has some solutions for keeping your UI zippy.

Posted by Kevin Carlson at 01:20 PM  Permalink |

I'm not sure how sensible it is for me to point out our own flaws here on the Dr. Dobb's Portal, but I'm afraid I can't pass this one up. If you hadn't noticed, we had a little server problem today. I hope this didn't inconvenience you too much. It certainly inconvenienced us.

While the IT team was slaving feverishly under the whips of their masters to restore server availability, I had plenty of time to contemplate the 403 error our server throws when the evil spirits take it:

"You have requested data that the server has decided not to provide to you. Your request was understood and denied."

That's reassuring. I'm really glad my request was understood, because my real concern here was that the server wouldn't understand that I was making an http request, and would instead think I was ordering a cheese pizza.

Now, before you accuse me of being intentionally obtuse, I do understand that this error meant something to someone when it was written. They always do. Perhaps the author of this particular server had spent a good amount of time in debugging sessions wondering "Is the request handler broken, or is it something in the security setup?" So maybe this error message specifically disambiguates between the two, and maybe that was a big help to the developer.

But once your code is out there in the wild, talking to people other than you, shouldn't you really make sure your error messages aren't coy, or worse, downright mean-spirited and capricious? Or at least you should go for the *nix "printer on fire" sort of error-message humor. And yes, I know that some people claim that the "printer on fire" message originally (we're talking decades ago, here) was intended to indicate a condition that represented a significant risk that the printer might actually BE on fire. This might be urban geek legend, or it might not. Either way, it pays to reevaluate the relevance of your error messages before your software gets anywhere near a user in its natural habitat.

Posted by Kevin Carlson at 04:46 PM  Permalink |

One of the hardest things we ever have to do is take a good, hard look at our foul-ups. It takes a real measure of intellectual honesty to uncompromisingly examine what you did wrong on that last project, and learn from those mistakes. But learn from them we must, if we are ever to write better and more reliable software. Ed Nisley takes a look at some very public screw-ups from NASA in his article "Failure Analysis."

Posted by Kevin Carlson at 06:09 PM  Permalink |