I remember that when I was on the support team, most of the time we spent, we were basically sitting heads down looking at screens, looking at these bugs all day. We were trying to work out where they come from, whether it was just a that a till had crashed and the system was… you know, maybe there was a bug, maybe it was just a known fault with one of the many third party systems we were talking to.
Most of our time was spent diagnosing the same bugs over and over again. Only there were eight of us, so I might see the same bug once every two weeks. Somebody else on the team who had been there longer had almost certainly seen it before. I thought wouldn’t it be great if we paired and passed that knowledge around ourselves so that we are all able to diagnose these bugs really quickly and didn’t tend to spend two days doing it. And I told one of the other guys on the support team this and he said “But that’s your job!”
And [PAUSE] I guess I’ve realised that… I kind of got the inkling at that point that the job of anybody who works with computers is to make themselves redundant as much as possible - and certainly to automate all the really boring things, or make them so they just take less time. So, we’re spending two days trying to go over and over pieces of code and run things and replicate errors and actually all we needed to do was talk to each other and get it down to half an hour instead of two days.
I remember that a number of bugs that week - we’d had a running total of about 100 bugs that we hadn’t been able to bring the list down at all, or it had been… well, maybe we had but it had been that way for three months. It got down to 20 within the first week of us pairing and our team leader, who had agreed to us pairing, just said “Yeah, it’s because it’s a really… it’s been a slow week.” [PAUSE] Which amused me.
But I think pairing gives you two things. First of all you share knowledge, so experts can pass on what they know and secondly you get instant feedback, especially when you’re coding. If you do something wrong and your pair spots it, at the first most appropriate point they go “You misspelled that.” You don’t have to go through the five to ten seconds it takes to compile the code, run the code, find out that it doesn’t compile and work out where the bug is and fix it; because your pair’s already watching over your shoulder, they’ve seen it, they’ve seen the little design flaw you’ve made, they’ve seen that you pressed CTRL SPACE and it fills in that method with the wrong method and you’re about to call something that you really didn’t mean to. So pairing is the first form of feedback. Your IDE is the second. A pair will normally spot something that doesn’t compile or that’s wrong, before your IDE does. Test First, acceptance tests, continuous integration, doing demos, QA, talking to your customers and releasing the code, you know, they’re your feedback loops in Agile. That’s what you want. You want to know when you’re doing something wrong so that you can get it right.
That’s Agile as far as I can understand it. I mean Agile is just getting feedback as soon as you possibly can so that you know when you’re wrong and if anything has changed you find out.
delicious
digg