An interesting conversation at work today. I was talking with the guy, L (no – a different one), who has been responsible for our IT for the past 3.5 years. L isn’t the guy that always does the work, although he can. His real job is as an engineer in the company and that’s his primary focus. However, he does handle the technology strategy and monitors the folks that do the IT work. (He and I are talking quite a bit since I’m trying to take some of the load off in this area).
Anyway, L made the observation that he is often frustrated by IT people in their approach to diagnosing a problem. His experience, both with our ISP and sometimes our desktop support, is that IT people will poke at a problem system in a non-systematic way, replacing components, etc., until the problem disappears. They may never identify the problem, but they did make it go away.
In my experience, this is not true across the board, there are many IT folks that do a post-mortem on problems, that diagnose issues methodically to pin-point the problem, etc. But he’s right – there are many that don’t.
The funny thing is that the methodical approach comes naturally to L, with his engineering background, but doesn’t come naturally to many other people and particularly people without any training in methodical testing. I recognized some of this back in high school. One thing that separated fair computer users from the great (and yes, this was back in the 80s) was diagnostic ability. My college roommate, for example, was lousy at diagnostics. He knew a fair amount about computers, but didn’t have a methodical approach for diagnosing problems.
KL was suggesting that people should identify experiments, knowing in advance what the different results would indicate. As an engineer, he called them experiments. However, many people with natural diagnostic ability do this instinctively. For example, the symptoms of the problem are known and could be either hardware or software. Some people naturally recognize this and do tests to rule out one or the other. Okay, the problem is in the hardware. Can we tell if it’s system or network? etc.
The funny thing is that I don’t think universities ever teach this skill. Computer Science does in a sense. If you can’t diagnose problems in your program in a rapid, methodical way, then you’ll probably fail out. But this seems to be more weeding out than teaching. IS courses and Engineering courses aren’t any better to my knowledge. I don’t think I’ve ever seen a “Debugging†course offered. So we’re left with people that can either perform diagnostics instinctively or people that can’t and replace/test parts randomly.
Am I missing something, are there courses in debugging? If not, should there be? I tend to think of debugging/diagnostics as a skill separate from coding or engineering. If that’s the case then it can and should be taught. Hell, there’s a whole television show (“Houseâ€) based on medical diagnostics – the least we can do is to teach future programmers, engineers and IT people the same skills.
That approach was emphasized in analytical chemistry and in a statistics class, as I recall from too many ago. Not surprising, since a major component of the stat class was experimental design.
Comment by bc — January 30, 2008 @ 11:24 pm
That doesn’t surprise me. I think that a lot of scientific (and other) disciplines explicitly emphasize diagnostic abilities. My father told me that in the advanced geology classes, your goal was to determine what kind of material something was. You lost points for doing stupid tests (like licking it 🙂 ), but the goal was to identify the material in some limited time period. I wonder if that’s, in part, why so many people without a computer science background do so well as sysadmins.
Comment by cec — January 31, 2008 @ 10:38 am
I never got taught systematic debugging as such, but had it trickled in to my brain from a variety of different sources over the course of my school career. Then there’s the radio engineer I worked for in high school – he taught me more about figuring out a problem than anyone did in the 18 years I was a student. I honed the skill somewhat while working for the tiny support firm in CH, but didn’t really get GOOD at it until I got here. And it took me a while, too.
Now that you mention it, I find that I’m trying to teach Nate that same mindset. “What’s wrong with it? What did you change? What do you need to try next?” Frustrating with the 4-year-old, but he’s starting to catch on.
I’d better stop, or else he’ll be an engineer or a chemist!
Comment by bryn — January 31, 2008 @ 11:51 am