I've been getting help preparing for my London to Paris bike ride (in aid of the National Autistic Society). I have a cycling coach - Jason - he's great. He's the dad of one of my son's friends.
I've worked as an XP coach, on and off, for many years and I feel like there is some level of analogy. Sometimes working as a coach has been better than other times; not everyone seems to know how to use a coach effectively, and I hope to indicate in this article that it isn't all down to the coach.
I'm just cycling a mere 200 miles or so; my coach has cycled across Ecuador. And Mexico. He knows what he's doing; I listen to his advice.
Jason hasn't cycled from London to Paris, but, he's done a lot of cycling. The fact that he hasn't done exactly what I'm doing doesn't matter.
I've been going for training rides with Jason every weekend. He coaches at a cycle club on Saturdays, so recommends a ride for me to do by myself on Saturday, then we go for a bike ride together on Sunday mornings. On Sunday mornings I don't tell him that actually I've decided to go shopping instead.
When Jason arrives at my house on Sunday morning, I don't tell him that actually I don't have a bike so we'll have to go for a run instead.
The analogy would have been buying a very expensive Wheelie Pointless Sycle from International Bicycle Makers (a tricycle with octagonal wheels), and then either struggling with it and getting no help, or asking Jason how to make best use of it and insisting on sticking with it because I've just spent loads of money on it.
Instead, I talked to Jason about whether to get a new bike; he suggested keeping my old rubbish bike until I had a better idea of what I need. My old bike was OK for training on, and Jason suggested ways to make it slightly less rubbish without completely replacing it - so I made those changes (things like having the tires actually inflated properly). I've now bought a bike, with his advice, that will be suitable for me and the bike ride.
When employing an XP coach, think about how to get the best use of them. There are things you can do to stop a coach being able to help you; don't do them. There are things you can do to help a coach help you; do them.
While at SPA 2006, I was talking to someone about pair programming. They said something along the lines of it being difficult to get accepted where they work. Someone else said that they'd not seen pair programming work anywhere. I piped up that I'd never seen it fail. I claimed to have pair programmed with around 100 people. Now I'm a bit more sober (it was a conference, after all), I've been reflecting on whether that was really true, or if I'm just full of ... beer.
When I first heard of XP, I liked the sound of it. Except for pair programming, which I thought was obviously nonsense. I was talking to a friend and ex-colleague, Tim Mackinnon, and he suggested that I suspend disbelief and try it for a few days. What's the worst that could happen? I might not like it for a few days then I could go back to not pair programming if I wanted.
So, I tried pair programming for a few days, pretty sure I wouldn't like it but willing to give it a go. That was late 1999 or early 2000 - I don't remember exactly - I've been pair programming, or cajoling teams into pair programming, most of my work time since then.
There's lots written about pair programming elsewhere; I'll just give a short list of what I've observed (which I'm sure isn't exhaustive).
Benefits:
- It's more productive overall
- You get higher quality code
- It's more fun
- Most people learn more by pairing (even very experienced developers)
- Inexperienced but capable developers learn lots very quickly by pairing
- It's more focused - less surfing, more working
- It's more focused - less gilding the lily, more getting it to work
- It's more focused - fewer dead ends, more working on what really needs to be done
Disadvantages:
- It's more tiring
- It requires a suitable physical environment (e.g. desks you can pair at)
- It's best if everyone works in the same place - remote pair programming can work well, but pairing is better in person
- It's best if everyone works the same times during the day - I've tried pairing on a team with "flexi-time" and it's not as good as having fixed hours
- It doesn't suit everyone
- It doesn't suit all types of work
I've got a bad memory, so I've had a look through my CV to remind me of the projects I've worked on since starting pairing. It turns out to be 14 projects, all with some amount of pair programming - more on what that means later. I've tried to remember as many people that I've pair programmed with as possible (that is, pair programmed with rather than just worked on the same project) - I came up with 85 names - 15 short of my claimed 100 - either I was exagerating (is that possible?) or, more likely, those people have been abducted by aliens who have then erased my memory of having pair programmed with them.
Of the 14 projects I've worked on since starting pairing, 9 used pair programming very nearly all the time for very nearly all the team's production code. The only non-pairing exceptions for those 9 would be quite rare. Of these 9 projects, 1 hasn't gone into production yet, 1 was cancelled for good business reasons, and 1 was an investigation not a delivery. Of the remaining 6 of those 9, all 6 went into production very successfully (although I have to admit, I didn't enjoy them all equally, dispite the success and the pairing).
Of the remaining 5 projects that didn't use pair programming as much, they did have, at nearly all times, some proportion of the team pairing - I would say averaging around half. Of these projects, 1 didn't deliver for various good reasons that I won't go into here, 1 was cancelled, again for various good reasons that I won't go into here, 1 I left before it was due to finish and I haven't heard how it's done, 2 delivered successfully.
To summarise, of the 14 projects, 8 successfully went into production. Of the remaining 6, 1 is still in progress, 1 I don't know the fate of, 4 were cancelled or didn't deliver.
hmmm. That's the big question.
It depends what you mean. I'd say pair programming didn't fail. It can be difficult to assess the real reasons why a project was cancelled or failed. As far as I know and can tell, those projects were cancelled or failed for reasons unrelated to pair programming, but of course, you'll have to take my word for it unless you were on those projects yourself - so I don't think I can prove my claim apart from using the "proof by repeated assertion" technique that I've been practicing over the years.
hmmm. Another good question for which "proof by repeated assertion" might be needed.
There were lots of factors in the success of these projects; good developers, good team and project management, test driven development, continuous integration, refactoring, etc etc. Out of all the factors that lead to success, I'm convinced that pair programming is a significant one.
I've never worked on a team that has tried pair programming and then given it up. I've heard of it happening, on a team very close to me in one case; just not experienced it myself.
I've introduced pair programming at a few clients where some people (both managers and developers) have been resistant. Some of those people have been "fully converted" and now advocate pair programming themselves. Some gave it a try but didn't take to it well, but didn't stop the rest of the team pairing. I haven't been on a project where pair programming has been abandoned.
Writing this article is (believe it or not - stupid me for not doing this sooner) the first time I've gone through all the projects I've worked on since starting to do XP/Agile and done any sort of assessment of them. I'm rather pleased that I have now. I might even do some more.
On the panel Structured Design and Modern Software Practices, Ed Yourdan told this joke (apropos someone using UML for user interface modelling - but he told it much better than I can):
An elephant trainer at a circus decided to teach his elephant to paint. After a while, he's taught it how to hold a paint brush. Later, he manages to teach the elephant how to dip the paint brush in the paint. Some time later still, he's managed to teach the elephant to stroke the brush against the canvas. Many years go by, and he teaches the elephant to paint better and better. Then one day, a reporter hears the story and comes to see the elephant paint. The elephant trainer says, "watch this"; he gets the reporter to sit on a stool and pose, and tells the elephant to paint a portrait of the reporter. The elephant paints deftly, with apparent confidence. After 20 minutes the reporter is excited to see the resulting portrait. The elephant trainer proudly turns the canvas around so the reporter can see it. It's just a mess of random colors. The reporter says "errr, it's crap". The elephant trainer is unperturbed. He beams with enthusiasm and pride "Maybe. But isn't it amazing - I've taught an elephant to paint!".
I'd like to coin the phrase "teaching an elephant to paint". In a meeting, if I say "yes, we could do that, but it would be teaching an elephant to paint" then I hope you'll know what I mean.
I've invented my own methodology1. It's called "do the right thing". The way this methodology works is, you "do the right thing".
If the build is too slow, [using XP terminology] you don't write a "technical story" to ask the customer for time to speed the build up; you "do the right thing" - if speeding up the build will improve the team's productivity (which it usually does) then you speed the build up. If the code hasn't been refactored then, do the right thing and refactor the code so the team can remain productive - the story isn't finished if the code needs refactoring. If something can be automated, e.g. the deployment process, then do the right thing and automate it. If some functionality doesn't have an automated test, then write an automated test for it. You don't need to ask permission to do the right thing - it's your duty and your right.
I have seen teams that have not done the right thing; a lack of refactoring, a lack of automatation, and a lack of automated tests are major causes of low productivity, low quality and low morale. You don't need to be "given time" to do the right thing - doing the right thing makes your team more productive and saves you time. Do not give in to short term time pressures - successful software2 lasts longer than anyone expects and takes longer to develop than is typically planned for. I have never seen a software project benefit from taking short term decisions. I've never seen a software project be unproductive because too much has been automated or through too much refactoring. I have seen many projects where there has been a direct correlation between not doing the right thing and the areas that have caused "unexpected" problems, taken longer than they should or resulted in production bugs.
1OK - not really invented, not really mine and not really a methodology. Joe Newton, Joe Walnes, W Edwards Deming and Kent Beck have all influenced this article/rant.
2Also known as legacy software.
My boiler needed moving this week as part of some building work I'm having done. Stick with me on this one - there might be a point (but you'll have to work out what it is). The plumbers worked really hard all day moving the boiler and lots of associated pipes. By the end of the day they were physically tired and mentally exhausted. It was a tricky job - lots of legacy plumbing that was more complicated than they had expected. Eventually, the job was done - but unfortunately, when they switched the boiler on, a fuse blew (because some wires had got jolted out of place when the boiler was moved) and by then it was too late to get a spare. They had worked until really late trying to get the job finished so that I wouldn't be left without hot water.
They came back the next day with a new fuse - the boiler worked, the central heating worked, there weren't any leaks. Unfortunately, the hot water didn't work. After some investigation it turned out that in their tired state near the end of the previous day, and in their hurry to get the job finished for me, they had got two of the pipes the wrong way around. They undid and re-plumbed those pipes and now it all works.
A client recently emailed (quote included here with his permission):
> It's funny but I think I can only work on Agile/XP projects now. I don't think I can "go back" to the old way. Thanks for the brain washing......
This got me thinking. I feel the same, and have done since soon after I got into XP in 1999. I've heard lots of people say the same over the last few years.
This causes a problem. Once converted to Agile/XP, you'll be dissatisfied if you have to work on a non-Agile project. Currently only a minority of jobs are working on Agile/XP projects, so if you want to be happy in your work your job opportunities become more limited once you've worked on an Agile/XP project.
Fortunately, Agile/XP projects are becoming more common now, so the situation for converts is improving.
Through careful selection of employer, and plenty of good fortune, I haven't had to "go back" to the old way and hope I never do.