Most of us have got so stuck on a bug that we’ve had to ask a colleague to look at it. We’re halfway through explaining the context when we see the problem. Our colleague hasn’t said a word.
The trouble with this is that most of us will spend two or three hours tearing our hair out before we call our colleague over. It’s understandable, because they are busy too, and we don’t want to look stupid. A few years ago I was aware that my team was losing a lot of time to this - perhaps a person-afternoon per week. In those days we programmed business logic in straight C. There’s no doubt that the better encapsulation of more recent languages has reduced the number of baldness inducing bugs we create, but they still happen (and where they involve subclasses battling overcomplex superclasses they can become really nasty).
So I wanted to save that person-afternoon, and tried an experiment. I bought a stuffed toy for each team member, and issued them explaining that they should try explaining the bug to the toy as soon as they got stuck, not three hours later.
It was an utter failure. The stuffed toys didn’t help at all. (Well, they might have contributed to an exploratory atmosphere where we really don’t mind low cost failures when trying new things, but they did nothing for the debugging.)
There was an obvious problem with people feeling that they might look foolish, talking to the toy, but I don’t think that was the main problem. I’ve recently asked a few people who program at home if it helps to explain their bugs to their domestic cats and dogs. It doesn’t.
We do need an actual person to be involved.
Table 1: Relating respondents’ gross properties to debugging usefulness.
Perhaps the problem is that we are hardwired to be good at imagining what our audience’s point of view will be, and looking at things from this point of view can be helpful if the audience is smart enough, but the hardware performs this complex processing on our actual environment. If we are actually talking to a stuffed and/or animal audience, that will be the internal model our clever brains set up for us.
This suggests that there might be a simple solution after all. Just email our quick and philosophical colleagues with our summaries of context and bug as soon as we get stuck. That will set up the right respondent model, where we see the problem in mid-flow we can discard the email and spare our blushes, and where we don’t we save our colleagues’ time.
Tell me, gentle reader, if it works for you, and I’ll do a follow up.