I never expected I would need to remove Pair Programming from my resume.

---

Five times in the past few months, the subject of pair programming was brought up by people who were interviewing me or teams I was working with. I listed it on my resume (http://www.clock.org/~matt/resume.txt) as one of the things I had experience in implementing on the BugScan projects.

In one, I sat down and was immediately affronted with "Why should I *have* to pair program? It's just going to slow me down!". In another place, which was implementing agile Scrum-like methods, it was "pair programming will never happen here, so just forget about it". I had learned not to bring it up in mixed technical company -- people have an almost violent reaction to the subject. Since it was on my resume, it was being brought up to me. I also get the people who ask me about pair programming, thinking they are going to enlighten me or that I will not be able to properly explain business advantage, technical debt, and cross-functional teams.

The decision to use and implement agile methods is highly subjective. Some people take Scrum and are continually late, extending their 1 month iterations by 1 week or more *every single iteration*. That's fine, just don't call it Scrum. Similarly, if you are doing (or think you are doing) Unit-Test First Test Driven Design/Development, stand up meetings, story cards, and other XP practices but not pair programming -- that is fine, just don't call it XP.

The problem with Scrum is that it claims that teams are self-organizing. I understand that has to be a selling point for developers, but it is actually not true. Similarly, some XP texts claim XP is not prescriptive, but that isn't true either. You have to have a cross-functional team and low/no technical debt at any point in the project to be able to scale up (or down) and deliver features at a fairly consistent velocity in a sustainable (non-death march) way.

You stay out of technical debt with ruthless refactoring to eliminate duplication throughout the system, made safe by an automated regression suite of unit tests. It is also necessary to make sure you are always moving forward on all fronts, verifying that the system's functionality is operating as the customer needs it with automated acceptance (system) tests. Delivering new functionality to make a customer happy means nothing if you break some functionality they are already used to without warning them.

Having a cross-functional team is critical for scaling the size of the team and keeping up morale and interest among the team. Some personalities like being the bottleneck of sole knowledge of a certain part of the system, but most find it boring and tedious. That is, it is usually the means to stay in a job, but not to advance to a better one. Anyways, this is the antithesis of a cross-functional team. A cross-functional team is enabled by having an understanding of (or help understanding) a part of the system, and not being "afraid to break something". These two things are handled in XP with pair programming and unit-test first TDD.

The above explanation may seem obvious, but it certainly isn't to everyone. Something that isn't obvious is that pair programming facilitates TDD in that it keeps honest programmers honest. Everyone experiences the rush of being on the verge of getting something to work, the pressure of the schedule, or whatever. That's when we lose the the rhythm of the Red-Green-Refactor xUnit pattern, and we start to get into technical debt. We get holes in our tests, we don't refactor and our design starts to degrade, etc.

It may seem small, but it all adds up and can cut the velocity of an agile project in ways that many people do not foresee until it is too late. I was explaining this to someone on a gig I did a few weeks ago and while he agreed, I'm not entirely sure he was going to be able to apply it. Much of this comes from strumbling along the journey, and reading the books mostly gives you an ends to the destination. I put it to him by quoting Dale Bozzio's spoken word from the Frank Zappa album Joe's Garage (http://www.amazon.com/exec/obidos/ASIN/B0000009SY/matthargettbl-20/103-5326745-1321413?%5Fencoding=UTF8&camp=1789&link%5Fcode=xm2) : "Information is not knowledge, knowledge is not wisdom, wisdom is not truth, truth is not beauty, beauty is not love, and love is not music."

Anyways, I removed "pair programming" from my resume to hopefully avoid having the more violent reactions I was getting before. Seems silly, but I don't make the rules.

Discussion: showing all 1 messages     [Show 3 7 14 30 100 *999* days or 10 *20* 30 50 100 999 messages]

2005-12-28

by robmyers:

[edit]

Hey Matt! Change is always painful, and you're still pretty close to the bleeding edge. Regarding the resume, perhaps more general statements regarding XP and agile methods would be less inflamatory. Regarding the efficacy of pair programming: I'm planning to write/present a paper on the topic soon, and I may ask to quote some of your comments, and/or ask you to contribute to and/or review the paper. The focus is going to be mostly on the value to the business, though I don't plan to neglect the developer. What should be no surprise to anyone is that what's good for the organization is good for the developer. People--and developers are always people, no matter what they tell you :)--tend to let short-term discomfort cloud their vision of the long-term value. As you and I know, pair programming can be uncomfortable, but it's a critical part of a process that prevents death-marches and costly failures.

Post a new message:

---