Andy Kelk

You might have read this answer to the question “Why are software development task estimations regularly off by a factor of 2-3?” by Michael Wolfe on Quora; if not, go ahead and read it now. It’s a great analogy and really helps to explain to non-developers why estimations are so often wrong. It also got me thinking about how Agile techniques try and solve the problems of estimation and planning. If we’d been using Agile, what could we have done differently?

I think the first fatal mistake on the journey was indicating a deadline before any work had been done at all. We knew where we were going and we knew roughly how long it might take (or so we thought). How about if we’d set off down the coast and then made the first call to our friends? After the initial difficulties, maybe we’d be more realistic about when we’d reach LA.

But what if we’d come up with that 70 day figure? Typically, there’s three choices: plough on and consider the reward worth the investment; kill the project entirely – turn around and go home; or try and negotiate on scope. How about our friends travel up and meet us somewhere near Hearst Castle? We still get to meet our friends before Easter, although it’s not ideal as they have to do some work they didn’t want to.

The other thing to consider is that our destination may change; maybe our friends move house (good thing we didn’t buy that detailed map of their area, that would have been a waste); or maybe they’ve upped and left entirely and we’ve walked all the way down the coast for nothing - what then? Maybe we should have had different goals – incremental goals that we achieved throughout the journey. Instead of our only pay-off being the meeting with our friends, how could we have delivered value throughout our journey? Well, if we changed our original goal to being a party with all our family and friends, maybe we could have met up with each of our family en route rather than having one big party in LA.

OK, so maybe I am torturing the analogy a bit; maybe you can never find a perfect analogy for software development (I’ve not seen one yet) but the walk down the coast is a great explanatory tool to show how a project that looks simple from the birds-eye view can get sticky once you zoom in.

When we started transitioning to Agile, we were lucky to have support from senior management as well as coaching from external consultants. Part of the deal was that we dived fully into XP including TDD, BDD and pair programming. One of the team rules (that’s literally written on the wall) is that all production code must be done in a pair. Before we moved to Agile we had a very strict peer review policy which mandated that all code committed to source control must be reviewed by another developer. Pairing provides that peer review as well as a whole lot more.

Now that we’re getting more comfortable with Agile and are becoming less reliant on our coaches, there are rumblings (quiet and far off ones, admittedly) around pair programming and I’m starting to feel that I have to justify the practice. I would have hoped by now that the benefits of pairing would have been obvious. It seems I may still have a bit of sell to do. I think I can build a convincing case in favour of pair programming.

1. You get the product quicker. There have been studies that show pairs complete deliver code quicker than programmers working solo. For example, one study shows that pairs did the same work 40% more quickly [source]. Double the people does not mean double the “man hours”; typically the number of “man” hours spent in total is around 60% more in a pair than with one person working alone.
2. You get a better product. Overall, teams where pair programming is used produce code with fewer defects than those who work alone. It’s very easy when pairing for one member of the pair to spot simple defects creeping into the code. Ping-pong pairing (where one pair writes the test, the other makes it pass) can also have a big impact as two people will tend to come up with more edge cases than a solo programmer.
3. You get knowledge sharing. One of the big problems in any organisation can be the creation of “islands of knowledge”. When pairing (and particularly when regularly rotating pairs), everyone gets to touch every part of the system. This means that you don’t end up with one person who is the only one who understands a certain part of the code.
4. You get skills transfer. Pair programming is a great way for novices to learn from experts. However, beware of assuming that once everyone’s been “trained” that pair programming should be stopped. We also use pairing to cross-skill the team so that, for example, developers learn UI skills.
5. You don’t waste time. No-one in the team is going to admit it, but if they’re left on their own they waste an awful lot of time. It’s not necessarily malicious, they just reach a roadblock and attention wanders; they read a blog, read some email, check their share portfolio and lose productive time. Not only does having a pair provide peer pressure to keep on working, it also helps prevent you getting to those roadblocks because you have two brains on the one task.
6. You have happier developers. The developers enjoy pairing – they feel more energised about the tasks they’re doing, they are supported in getting the work done and they are working together as a team. Pair programming can be a leap into the unknown for those who haven’t done it but after taking that leap, the outcome is almost always positive.

Personally I think that number 6 alone is worth doing pairing for, but I know that I’m going to have to work hard to keep pairing as a core part of our development practices.

Look around any office and you’ll see that people love to personalise their space. Like any other office, we have our fair share of personal effects – family photos, fishtanks, novelty items, printouts of webcomics, funny signs (although we’ve stopped short of the “You don’t have to be mad to work here…” variety). It’ll probably come as no surprise, then, that one of the hardest points of the move to Agile & pair programming was the move away from people’s “home” desks.

As mentioned in a previous post, we’ve significantly changed the office layout and are continuing to change with an investment in new desks for the developer pairs to work at. When looking at plans for the Agile areas and assessing the usage of space in the current layout, one thing that soon became obvious was that everyone having their own large desk with a desktop computer and two monitors on when they are pairing for most of their day is not an efficient use of space.

When you come to the bare bones of people’s workspace requirements, they need three things: firstly, a desk at which they can pair with another developer; secondly, a desk they can work at if they’re not pairing (using their MacBook); and thirdly, somewhere to keep their personal items. This can be achieved with a number of “hot” desks that people can rock up at with their laptop and a series of storage areas (cupboards, drawers, etc) for people’s belongings. Personally, I like the idea of hot desking – a change is as good as a rest after all. Even with a desk of my own (strewn with CVs, documents, books and coffee cups as it is), I often find myself lodging in a spare meeting room or sitting in reception in order to get things done away from the distractions of my “normal” work environment.

My concern though is that there’s a risk of de-personalising the work environment if nobody has their own desk. Where do the USB missile launchers, fake fishtanks and kindy masterpieces go then?
There are other things to consider when people lose a “home” desk, such as what happens to the phone they used to call their own? One of my team recently ran into this problem:

I’ve lost my old desk phone. I left it behind after the 4th or 5th desk move, and have no idea where it is. However, people still call it, and leave messages.

I checked my voicemail today, and found a message from the 25th May; my Dad is waiting at reception.

Another of my team spoke of the change from his contracting days when he deliberately made his work area a very personal space in order to offset the feeling of impermanence that contracting can bring. Now he finds himself as a full-time employee but without so much as a picture on his desk.

Ideally I’d like everyone to have some kind of horizontal space they can call their own. It doesn’t need to be a full-sized desk, after all they’re only there 5% of the time; but there should be somewhere you can return to and feel like you’re on your own turf. Ultimately it’ll come down to getting the best possible area for the pairing areas and working out what’s left for personal space, but I’ll do my best to give everyone a home away from home.

This may not be news to long-time office dwellers, but the way your work environment looks and operates is really important. Our office has a history with another, very traditional company and the layout really reflects that. It’s nominally open plan (as in, there are no separate offices), but the lines of sight and communication are really closed off. Apart from the pillars and obstructions (a huge compactus which no-one on our floor uses, for example), the partitions between working areas are of a sufficient height to mandate meerkatting if you want to speak to anyone else. The desks all face away from each other and there’s loads of wasted space because of little corner returns on each desk.

When we launched our first pilot Agile project, we found a suitable area, ripped out half the desks and plonked a big, functional table in the middle. Pairing workstations were put on the table and everyone crowded around and started coding. After some initial misgivings about losing personal workspace, the team soon got to enjoy the environment we’d created and it now seems like a natural use of the space.

Soon after, we adopted Kanban work practices for our maintenance and support team; pairing was “encouraged but not mandatory”. Some brave souls had a go, but the desks just aren’t conducive to effective pair programming. They really lend themselves to a “I’m doing some coding, you’re just watching me” behaviour.

So, on launching a second Agile project, I was concerned that getting the pair-programming right was going to be an obstacle to really adopting the rest of the practices. I scouted the office looking for suitable areas where we could put in a central table, but we’d already used our one option for that on the first project. We finally settled on a row of desks at one end of the office that I refer to as the plague pit (although the team have adopted the slightly less doom-laden “play pen” instead). One Friday afternoon, the screwdrivers came out and the pointless corner returns on each of the desks came off. The change from that small action was dramatic – not just in the feeling of space in that part of the office, but also in the ability to line up pairing machines along the desk and have people instantly in an environment where pair-programming seems the natural choice.

Our next step is to do a piecewise refactor of the office environment. The architects have been engaged and we’ve got some cool desk layouts planned for the original Agile area. Our longer term plans also include plenty of whiteboards and spaces for putting up big visible project artifacts. It’ll be great to have a space that was designed with Agile in mind, but we’ve also shown that an office can be moulded into a workable environment with a bit of creativity, some screwdrivers and an investment of time.