Looking for a Good, Free Resource
After introducing the concept of pair programming, I went looking for (free, of course) resources to further explain how it worked and what the benefits are. At first I was surprised at how little I found. Sure, there are chapters in all of the XP books on pairing, but I was looking for something that I could just send a link to in an email. I figured there would be lot of good stuff to choose from.
I think there is not a lot of profound work on the Web explaining what pair programming is because, at it’s core, pair programming is pretty simple. In addition, there is not much written on its costs and benefits because it is a relatively new practice and doesn’t have a whole lot of academic research done on it.
What is Pair Programming?
As is the case with a lot of things, a good starting point for a brief overview of pair programming is to go to the Wikipedia entry. It has a surprisingly good, brief overview of the what and the why of the practice.
The Costs and Benefits of Pairing
Once you’ve got a basic idea of the concept, the next step is to analyze the pros and cons of the practice. For this, I recommend Alistair Cockburn and Laurie Williams’ paper The Costs and Benefits of Pair Programming. This paper appears to be about eight years old, but is still perfectly relevant. This might be the best free, less-than-ten-printed-pages introduction to pair programming.
Installing Pair Programming
My limited personal experience was pretty successful, but there are so many dynamics that come into play when introducing a practice like this into an organization where the concept in entirely new. So, I was still looking for more resources on how to introduce the concept and the practice of pairing. I ordered a copy of Pair Programming Illuminated by Laurie Williams and Robert Kessler. I’m only on the second of twenty-seven chapters, but what I’ve read so far seems to be insightful and helpful. I’ll post more about what I find as I work through it.
I was a long-time skeptic of pair programming. More than anything I think I was resistant because the prospect of sharing a keyboard with another developer sounded unappealing, even if it worked. Like most developers, I like to tinker with code… try one thing… Google for other people’s solutions to the same problem… tinker some more. How would this work in a pairing situation?
People with more agile software development experience than I had would say two things: 1) it works, and 2) you have to try it to believe it. But for years, I only dabbled in it, never getting past the discomfort of it–sort of like deciding to take up running. You put the shoes on and huff out a mile or two only to feel terrible and put up the shoes for another six months until the guilt wells up again. You don’t make the breakthrough to enjoying it and realizing the benefits until you get better at it and get past the initial discomfort.
It was only after trying it for a sustained period of time at VersionOne that I came to appreciate that both things I was always told. It worked and I had to try it to believe it. The increased focus and benefit of talking through the minor design decisions that get made as we write code more than made up for any productivity loss of having each of us work on different problems at the same time. At VersionOne, we even found, during early feature design stages, we would have three of us, Visual Studio, and a whiteboard. We would design and code as a team. The consensus was that we tended to craft our best solutions and write our best code during those sessions.
Now I find myself in a position of advocating pair programming at Agentek. As you might guess, I’m saying things like “It works, but you’ll have to try it out for yourself to believe it.”
One of the first things I’ve been occupied with on the new job is interview candidates for software development openings we have. In recent years, I’ve been drawn more and more to get involved in the hiring process. I believe there is no more critical, leveraged action you can take toward making a software company successful than finding and hiring the right people. Having the right people is more important than programming language, platform, or methodology. The best people will overcome poor technology choices. The wrong people will eventually fail no matter what technological advantages they have.
In Good to Great, Jim Collins lays out a principle he calls “First who… then what.”
Executives who ignited transformations from good to great did not first figure out where to drive the bus and then get people to take it there. No, they first got the right people on the bus (and the wrong people off the bus) and then figured out where to drive it. They said, in essence, “Look, I don’t really know where we should take this bus. But I know this much: If we get the right people on the bus, the right people in the right seats, and the wrong people off the bus, then we’ll figure out how to take it someplace great.”
To a large extent, I think it is the same way with software. Assemble a great team, then decide what to create. In the world of commercial software, it rarely works quite that way. There is almost always a product in mind before the team is assembled. So, it’s not feasible to get the right team, then decide what to build, but it is realistic to get the right team in place, then decide how to build it. The how is always what separates good software from bad anyway.
As I’ve been immersed back into the hiring mindset, I continue to be struck by how many people who make their living developing software are so weakly grounded in the fundamentals. More on that later…
I have just finished up my time at VersionOne and am a couple of weeks into my new position at Agentek. It was a tough decision to leave VersionOne. The company is well positioned to capture a large share of the growing agile project management tool market, there are a lot of talented people there, and I have a lot of friends there.
However, the opportunity at Agentek was too much to pass up. Here I will guide the development of the complete application stack on the .NET platform for desktops and handheld devices. The company is also early in its transition to agile methods.
While VersionOne is loaded with senior people and mature processes, Agentek is in the beginning stages of moving to the next level of maturity–both in terms of process as well as engineering practices. I’m stoked about the opportunity I have here to impact the overall success of the company.