In the NaBloPoMo review for 'G', Rashenbo mentioned the following:

I liked [blog] and wanted to comment... but Wordpress was making me register and I get tired of registering and entering captcha codes to make a comment... so I just scooted along!

That gave me something of an epiphany. I have only had one comment on this blog since its inception. I know it isn't the most interesting of topics or aimed at the widest of audiences, but I really would like feedback on the ideas. I didn't think that my fear of comment spam was restricting things, but I should have thought about it. I also hate registering with some site I don't really know, for them to do FSM-knows-what with, so why am I forcing people to do the same? I just changed the policy and now anyone can comment, without having to register. I'll rely on the magic of Akismet to stop comment spam for me. Enjoy the new and improved Shouting Distance Blog, Now With Less Tyranny(TM).

I wanted to break out of the Distance Debugging discussion for a moment (to return later today) to highlight a new feature I just added up top, the Distance Debugging Help Desk. In brief, I want to help you fix your problems with computer hardware and software in order to get practice debugging. The only thing I ask in return is that I can post about it, and if you have a blog, that you link back to me if I fix your problem. Anyway, there are a few caveats that are listed in full in the page linked at the top (basically, I can't fix everything, I'm very busy, and please don't sue me), so check that out and then email me at helpdesk (at) distancedebugging.com if you are so inclined.

For one very brief example, I stumbled across Alex Hopmann's Blog a few days ago and he had noted a problem where hard drive accesses caused his computer to slow way down. It just so happened that recently I was investigating problems with DMA on Linux, and although it was a Windows computer, the symptoms were exactly the same. I emailed him and with that clue, as he explains in this post, he was able to resolve it with no trouble and got his laptop much more functional again.

Anyway, I can't guarantee a fix for you would be that simple, but it can't hurt, can it?

In an attempt to lay out a lot of ideas all at once, I decided to join up with the National Blog Posting Month, the lazy (or let's say, time-challenged) stepcousin of National Novel Writing Month. The idea is pretty straightforward: just post every day for the entire month. I decided that I will use this opportunity to lay out what I see as the major pieces of the skill and theory of Distance Debugging in the hopes that others will comment and improve on the ideas, or at least tell me if this stuff is trivial or plain wrong.

I'd like to start by talking about the skill of debugging, leaving distance debugging aside for the moment. I was having a conversation with my dad the other day about how he was dissatisfied with the company that provides his firm with IT support. I made the offhand comment to him that the problem is not that they don't care about problems, it's that they aren't any good at finding and fixing them. To me, this is a critical but hidden issue. Everyone has their favorite horror story about technical support, but no one seems to be stopping to say, "hey, maybe we should think about how to get better at fixing things."

In the world of software development, the problem gets worse. Estimates vary widely on the amount of time the average developers spends debugging, but there is general agreement that it's at least 50% of their time (and up to 80% or more). However, while there are a zillion books that can teach you the basics of programming, and hundreds of titles devoted to every miniscule aspect of design, there are only a handful of titles devoted to debugging. Why is it that the thing we probably spend the most time doing is the hardest to get any good information about?

I honestly don't know, but I have a few ideas:

1. Debugging is seen as something you either know how to do or you don't. It's not teachable, so why write or read a book about it. This is probably totally false.
2. Debugging is seen as something that you pick up through experience, and that's the only way to do it. There's no point in trying to come up with a curriculum. It's true that experience helps, but this kind of argument is always made in nascent domains.
3. There isn't a good theory of debugging, so we wouldn't know what to teach. This is partially true, but as the few books on the market show, you can have a set of rules or guiding principles as you do in any scientific field.

So I'm starting with the assumptions that debugging can be taught, that it is very important to teach, and it's really just a matter of figuring out what to teach. Having worked in the field and displayed a knack for finding and fixing problems, I think I have a coherent way of describing the process. I come from a different perspective because I believe that most real-world problems have an element of distance in them (more on this tomorrow) and this is where the current thinking in the field falls short.

Tomorrow's entry: Distance is Everything.