Caveman Debugging

I recently heard about this new term: caveman debugging. It's basically where you make a program that you think might have a problem diagnose itself while it is running. Here and there you make it output useful information that might lead you to understand what is wrong - and what you can do about that.

It's a rather common thing and I do use it from time to time. I mean, it's nice and all to have a debugger, but sometimes it just works better to do it the old-fashioned way. Or maybe you just happen to be working in an environment with no debugger. Or just not a good one. Well, no matter what your reason is this time, you might well be wanting to use this technique.

And as a matter of fact, I had been looking for a name for it for a while now. How else can I refer to it clearly. Some call it printf-debugging, after one of the traditional functions used for this purpose (the printf function from C formats text and outputs it to the command line), but it's a little unimaginative. And it just doesn't fit all languages.

This term I read about, caveman debugging, has none of these problems. It really does capture the technique, but at the same time it doesn't really look down on it either. At least, not in my eyes. I mean, the word caveman sounds like strong and powerful, yet crude. Well, that's exactly what it is, so no complaining here. It also sounds like it's old, and that's what it is - it is the first type of debugging that was around - however, it does not sound like "superseded" and it is not. It's still a useful technique and should not be shunned. Well, that's why I like the name. However, the term has its own problem: people don't know it and may not guess what you mean.

So I propose a solution to that. Just use it. All of you. Write about it. (I did... uhm, am doing?) Tell each person who wonders what it is what it is. Just use it. From this moment on, it's a term in my book. And that means it's now my responsibility to spread the word.