|
I've found that while pairing is sometimes useful, it's often not. People, even good programmers, have different brains that work differently, and that sometimes gets in the way of pairing. You get into stupid arguments about the right order in which to do things, or waste time bikeshedding about variable/function names when really you just want to sketch the whole thing out and clean it up later. And that's assuming no one ever mentally checks out. If everyone pairs 100% of the time and you don't have these problems, what you probably have is a monoculture where no one thinks differently. And if you do have those problems, you probably lose more productivity than you gain from someone saying you forgot a semicolon. The monoculture point deserves elaboration. The job postings for one particular consultancy that does 100% pairing are pretty explicit about requiring everyone to use the same particular text editor. Think of the five or ten best programmers you know--do they all use the same text editor? People say that their company has a "culture", and if you don't fit in then it doesn't matter how brilliant you are. In other words, they place a higher priority on being just like everyone else than they place on being good at what they do. So already, they're handicapping themselves by not hiring the best people. On top of that, they think they have a recipe for a "company culture", but really what they have is a recipe for groupthink. Real cultures have diversity. Healthy, creative cultures are the most diverse of all. So not only are they not hiring the best people, but they're constructing a social environment among the people they do have that effectively makes them more stupid. 100% pairing is probably one of the worst ways to develop this kind of monoculture, because there's even a brain difference between people who naturally are good at pairing and people who aren't. So not only are you excluding the people who don't share your particular text editor and way of thinking and working, but you're excluding those people within the already exclusive population of developers who can pair effectively. And then you complain that it's hard to hire people. I went to a conference once where someone gave a talk about how awesome his company culture was because they paired 100% of the time and after work they went out to dinner or the bars together and talked about work and came back to work to work on the ideas they thought about during dinner. Someone asked a very insightful question about whether this culture excluded people who might have had families, and they responded that everyone in their company were young, single men. If I ran a company and I discovered that all of my employees were bachelors with nothing better to do at night than hang out with their coworkers and work some more, I would stay up at night worrying about that. What about my company or my hiring practices is so broken that I only hire people exactly like me? One thing I've found enlightening to think about is that nearly all formal methodological dogmas are promulgated by people who are selling something. Who's going to make more noise--someone with some altruistic desire to advance the state of software engineering, or salesmen? If you convince everyone "agile" is a good idea, then maybe they'll want an agile consultant. If you're going to sell scrum master training courses and certifications, you have to sell the idea of scrum. If you're trying to sell CASE tools and you're not clever enough to design software that can be adapted to different processes, you need to sell people on using the process you designed the CASE tools around. Likewise, if you're a consultancy trying to differentiate yourself from all the other consultancies, you need to sell people on your process, and pair programming is a process that conveniently allows you to double your billable hours. That allows you to fully utilize all your devs on a smaller number of projects, which reduces the overhead involved in bringing projects onboard. |