 (영문).files/ibm-logo.gif){kind=logo}
 (영문).files/c.gif){kind=small}
|
|
|
| IBM home | Products & services | Support & downloads | My account | ||
|
|
| ||||
|
Demystifying Extreme Programming: Winning with a pair | |
 (영문).files/icon-discuss.gif){kind=icon}  (영문).files/icon-pdf.gif){kind=icon}  (영문).files/icon-email.gif){kind=icon} |
|
| ||||
| ||||
|
Two heads are better than one
Programming has been essentially a solitary profession for the last five decades. Oh sure, programmers talk to other people, especially during the requirements-gathering phase of projects. But once the coding starts, programmers in most companies tend to dash for their offices or cubicles to be alone. Managers don't mind too much, because programmers working alone fit into the work plan easier, and having many people working on discrete pieces of the problem at the same time seems more efficient. Then along came XP proponents who said programmers should write code in pairs. If you tell that to most managers and programmers, you're bound to get some weird looks, suggesting they pity you for being so misguided. The reason is because they either don't understand what pairing really is, or they do understand it, but think it's an unwise or crazy approach to coding. What pairing is -- and
isn't
I can respond to the first two reactions easier than the third, because the first two usually come from people who need more information. In the first case, the person has no idea what I'm talking about, so I give him a quick definition: Pairing is two people working on the same programming problem together. As I said in the second article in this column, "XP distilled revisited, Part 2," the mechanics of pairing look like this: [Pairing] typically means two developers sharing one computer, one monitor, one keyboard, and one mouse (I've found two monitors, two keyboards, and two mice to be more enjoyable and more efficient, but the single version works fine, too). You and your counterpart sit at the keyboard. One person drives (the "driver") and the other helps him find his way (the "navigator," or "partner"). If the driver gets stuck or frustrated or loses his train of thought, the navigator and driver can switch roles. In fact, that should happen very often, sometimes every couple minutes (or even more frequently than that). Once you get used to it, and to the particular person you're pairing with, you slip into a flow, switching back and forth naturally. When I describe pairing to the "Huh?" people in those terms, their reaction usually shifts to "That sounds interesting" or -- more likely -- "That's insane." Either they have questions about how pairing could work in their particular situation (see the accompanying discussion forum where you can ask these questions and see my responses to those who've come before you), or they want to convince me that it's just not a viable option. I'll get to the "That's insane" folks a bit later, but first let me talk about the most intriguing question I've heard: Why pair? The benefits of
pairing
Risk can be paralyzing for most teams. Think about your last project. I'll bet you can think of something you wanted to do, but played it safe because your idea seemed too risky. Join the club. The best way to reduce risk is to make sure everybody on the team is broadly familiar with all parts of the system and with all changes to the system. Chalk talks and design documents are helpful, but they can't spread knowledge well enough and fast enough for most fast-paced projects. The most efficient way to spread knowledge is for somebody who knows the code to work on it with somebody who doesn't. Pairing is one of the greatest tools managers and teams have to reduce risk and keep change from killing a team. When teams pair, all design decisions and code changes get made by at least two people. By pairing programmers, managers ensure that more people are familiar with the code and the changes it's going through. In addition, code written by a pair is almost always better than code written by an individual. Two heads really are better than one, especially for design decisions that affect the entire system. No matter how smart a programmer is (or thinks he is), a second opinion helps avoid bad decisions that arise from ignorance, arrogance, or simple oversight. While many programmers probably don't have much trouble staying focused, it certainly helps to have somebody else keeping the rest of us mere mortals on track. It's especially helpful when you're trying to solve a frustrating problem. When you feel like giving up, there's somebody else there to encourage you and keep you going. Teams are also less likely to neglect tests or other important details -- that alone increases productivity. On my pre-XP projects, my teams slowly picked up speed as the project moved along, but eventually slowed down again as bugs piled up. On my XP projects, however, my teams get unbelievably fast very quickly, and then stay there. Recently, for example, my team's velocity went from 14 story points in iteration one, to over 60 story points in iteration five (see Resources for more information about the XP concept of story points). The primary reason was that our code got more mature much faster than I had ever seen before, which allowed us to move more quickly as the project developed. And when teams pair, code is constantly being reviewed by at least one person. That's the best code review I've ever heard of. The XP value of Simplicity suggests everybody on my team ought to do the simplest thing that could possibly work, both for code and for process. Pairing might not seem simple when you start. It's a bit uncomfortable, and it takes some getting used to. But the values, principles, and practices of XP don't encourage you to do the simplest thing possible -- they encourage you to do the simplest thing that could possibly work. If something is simple (say, having everybody code alone) but it isn't effective, than it's not the simplest thing that could possibly work. Sometimes the simplest thing that could possibly work is hard until you get used to it. Pairing is a good example. In my experience, not pairing doesn't work as often as pairing does. Why some programmers hate
it
Programmers tend to be a proud lot, and many are prone to delusions of grandeur. Sometimes they can back up the bravado with prodigious intelligence and skill, but even those who can't probably think they can. Still, even the best programmer in the world can learn something from the lowliest hacker -- a fact many of them forget. When a programmer says pairing will slow him down, he might be right. Perhaps working with somebody else will reduce his individual speed. But the benefit of having two minds attack the problem can cancel out any short-term dips in individual productivity. What most programmers mean when they say pairing will slow them down is, "I'm better than that other guy, and carrying him will hold me back." Pairing isn't for everyone. Spending all day in a cubicle bouncing ideas off another person is probably not your typical programmer's idea of a good time, and it can be stressful. But the stress can pay off. Relating to people is often more difficult than being alone, but sooner or later every programmer is going to have to speak to other human beings (or at least other programmers) in order to get the job done. Pairing is a habit that can help make the human interchange feel as normal and non-threatening as coding. Even if a programmer buys the idea that communicating is a better way to learn and create, he still probably feels like he needs some "alone time" to figure stuff out. I can understand. Sometimes a little concentrated thought, with nobody to have to explain myself to, is what's necessary to solve a problem I'm working on. I'm convinced, though, that this need for alone time really is a symptom of something much deeper. Of all the reasons programmers might give for why they think pair programming is stupid, the scariest one is that they're afraid. This is human. Nobody likes to put his weaknesses and ignorance on display. Many programmers have a hard time admitting that they aren't brilliant, but they have an even harder time letting it show. They hate the idea that they might be proven wrong. But we need to expose our weaknesses in order to learn from them and grow as a result. Pairing can make you more whole as a professional software developer. Why some managers hate
it
Especially in the last hundred years, managers have been conditioned strongly to believe that more than one person working on the same task is inherently inefficient. In some industries, such as manufacturing, that might be true. But it's not necessarily the case for knowledge work such as software development. As soon as someone starts talking about pairing programmers, though, many managers say, "That's inefficient." I usually say, "That's right, and that's good." Creating great software isn't an efficiency optimization problem. It's about invention. Invention is a messy business where efficiency doesn't work. Now, if two people sit together, but one person simply looks over the other's shoulder and doesn't participate, that's truly inefficient. If, on the other hand, two programmers are working to solve the same problem, you get the benefit of two focused minds. The solution will almost always be better. If one mind has a flash of brilliance, the other might balance it by keeping it focused on the simplest implementation of the idea. If the other mind goes for simple and passes right on to stupid, the other can stop the madness. Manager conditioning on this issue is wrong, and most managers don't (or can't) question it. One of the reasons many managers shy away from pairing is that they're afraid of how it might be perceived. If their boss sees programmers sitting together looking at the same monitor, he might storm into the manager's office and demand to know why "resources" are being wasted. If a peer drops by to discuss something and sees programmers pairing, word might get around that the manager has lost his mind. Those are real fears. But I suggest that the damage to the team's real (as opposed to apparent) productivity will far outweigh the damage to the manager's reputation. Results matter. Suppose he lets his programmers pair, rather than having everybody work separately. If the pairing experiment produces better results more often, the means of getting there becomes less of an issue. It might even become the standard. Notice, incidentally, that I said the manager lets his programmers pair. What if his programmers don't want to? This, I think, is the biggest reason most development teams don't pair. I've spoken to many managers who think pairing sounds like the right thing to do. Those same managers, however, tell me that their programmers threaten to quit, in some cases en masse, if forced to pair. You've already read why programmers might react that way, but what's a manager to do? I'm convinced there are only three options:
Before I get flooded with responses telling me how hopelessly naive I am, let me say that I realize the first option isn't typically available. Most managers aren't that empowered. The third option is a bit drastic, but more on it in a moment. The second option, however, might prove interesting. Some research, albeit with university students, shows that programmers who initially hate the idea of pairing end up liking it after they try it (see The Costs and Benefits of Pair Programming by Alistair Cockburn and Laurie Williams in Resources for more details). Forcing people to do something is heavy-handed, but sometimes it's necessary to jolt people out of their collective or individual rut. Try forcing people to try pairing for a very short time. If they object, emphasize the fact that it's only two weeks. Anybody can put up with anything for two weeks. Those who aren't convinced after two weeks probably won't be convinced after two months -- and even if they would be, you'll probably never find out because they would never try it for two months. A manager's strongest hope is that two weeks will convince most programmers that pairing has promise. If not, you always have options one and three. What a good manager cannot do is mandate pairing for the long term. That's beyond heavy-handed. It's dangerous. It's a good way to make enemies. If your programmers are so mad that they leave, you're left holding the bag. Experiments are fine. Changes after you get some team buy-in are fine. Oppression usually fails.
What pairing is really
about
|
| |||||||||||||||
|
| About IBM | Privacy | Terms of use | Contact |
 (영문).files\c(1).gif){kind=small}
 (영문).files/dwlogo-small.gif){kind=small}
 (영문).files/c-j-xp.jpg){kind=small}