The First Rule of Programming: It’s Always Your Fault

March 22, 2008

Coding Horror has a post up that is really close to my heart – debugging.  Years and years ago, my PhD topic was specifically to do with this topic and for a few years I studied programmer psychology (why programmers create bugs in the first place – what it is in their "mental model" that breaks down) and the tools that can be used to help them overcome these issues.

In the end, I developed a tool that helped programmers find "known" bugs in their code called Signpost – there’s an IEEE Software paper about it and a few webpages where you can read more if you are interested.  The general idea is that there’s a lot of knowledge out there in how programmers screw up using APIs, or how those APIs/libraries are busted.  Although the Coding Horror post correctly says that the vast majority of the time it’s your fault, sometimes that just doesn’t help and you can be scratching your head over something not working for a while – wouldn’t it be nice if you could quickly see if anyone else had the same problem and had a solution?  Microsoft has been interested in integrating it into MSDN/VisualStudio a couple of times, but we’ve never got close enough to actually pull the trigger and start getting anyone to work on it.  Unfortunate, but one of those things – I’m hopeful the time may be right at some point in the future.

There’s a couple of other bits of info in the work that I did that I’d like to point out in the context of this article.

• The biggest thing that gets in the way of programmers fixings bugs is called the "cause-effect chasm" – the further away (and not just in lines of code – time and conceptually as well) the cause of a bug is to where the programmer "sees" it, or is looking for it, the harder it is for them.
• Most debugging tools don’t help the programmer as they only work in one direction – forwards – and the programmer has to work towards the cause, moving their starting point backwards each time.  "reverse" debugging tools/techniques (slicing, tracing, debuggers that allow "step back") can help out a great deal
• By far the most well used debugging strategy is "debug by printf", where additional lines of code are added (sometimes quite liberally) to "print" program state as it’s running!  It’s astounding how few advanced features of debuggers are used.
• Even though there’s been some really interesting research on new debugging tools/methods/techniques, what programmers are actually using hasn’t really changed in years, and I find that quite disappointing when I look at all the other advances we’ve been making in software development.

Edited To Add: Nice post here describing the basic principals of DLL hooking (one of the techniques used in Signpost), and how it can be used for "bad" as well as good

Posted in Misc