We tried to use Extreme Programming (XP)practices (http://www.extremeprogramming.org/) in our current project. I like the ideas, but something inside tells me this is not very natural thing for software developers (at least for those I have), so my question is: What do you think about XP and do you think it is a good way to run software development project?

-- Anonymous, November 18, 2000

Answers

The thing I always get fixated on is sharing a computer with someone and doing all development with one person looking over another's shoulder. I tend to be a control freak with my computers and like to have absolute control (as much as that is even possible :-) over my machines. Plus, how long before one of you takes a chainsaw to the other after about the thousandth time they've pointed out a missed semi-colon. I also find it very difficult to do any kind of deep thinking with someone standing over your shoulder. Like a lot of programmers, I enjoy the solitude of the work.

-- Anonymous, November 18, 2000

The company I work for is transitioning to XP. They are already using a number of XP practices, and are increasing them as people get used to each one.

The rest of this note is my personal opinions.

I think some things about XP are great ideas.

For example, keeping a fully-functional large test-suite on hand in the code is a great idea. I've always put test code in my apps, but I never thought to go to the lengths that XP does. I'm trying to do this to all my stuff now.

Some things about XP are fine in moderation.

Working with other programmers at the keyboard (pair-programming) is really great - sometimes. Doing it full-time doesn't work for me. I can only think shallowly with someone sitting next to me typing or chattering. Don't we have stacks of research and empirical evidence to say that quiet offices are best for developers? I couldn't work well in the madhouse exemplified by the pics in Kent Beck's book.

I think some things about XP are crazy.

No design up front? Great if you've worked on that kind of system before and hence have the design in your heads already. I'm reluctant to believe that a bunch of code tailored for Design X can be economically refactored into Design Y when you realise your design was wrong up front.

-- Anonymous, November 18, 2000

XP is not realy management methodology, it's more of a philosophy. It's great when you have two ppl who just click when they do it (well XP, anyway ;).
I think you need to promote the right environment & help grow the practices that work for your ppl and your project requirements. Kind of using the approach used by James's organisation above.

The trick is not to use something exclusivly, keep trying new things and adopting the things that work best for you.
Working in pairs is pretty tough, but really does improve your focus, your abillity to think openly and your communication skills.
The thing I really like about XP, is that it changes the way you create your code, it becomes more readable & re-usable. Now, that's gotta be a good thing.

One thing that has been troubling me is the 'not having a desin up front' I'm still not sure about this one. I've found that it's important to have just a few clear project goals, then come up with the rest of the system around that, but, it really does severely limit the number of ppl you can have working concurrently on different parts of the system. Afterall, the design's primary use 'should' be to communicate a vision of what you hope to achieve. I.e. the design remains flexible & should accuratly represent the system at all times when it's being built, not just what you originally started out doing. to quote Steve McConnell (also quoting) in Rapid Development : Taming Wild Software Schedules
"The idea is not to do what you said you would. The idea is to do as much as you can with the time and resources available"
(I may have bastardised the wording, it's pretty close to midnight here now ;)

-- Anonymous, November 21, 2000

A lot of people seem to like most of XP, but hang on the Pair Programming thing. I haven't done much of this myself, but I have seen it work pretty well.

At my last assignment, we had a pair of troubleshooters that floated from workstation to workstation fixing crashes and deadlocks on a complex multithreaded, multiprocess C++ project.

Dave would scratch his head. Steve usually typed, but they had a great give and take as they worked. Their comments reminded me of a long married couple that knew each other so well that they only needed a few words.

The result was much greater than the sum of the parts, and they solved problems that neither could solve by themselves.

Of course this isn't exactly the way it's used in XP. These guys always worked together.

(Sometimes I substituted for the missing guy, and I always felt like an imposter trying imitate the missing partner.)

This was also fixing bugs rather than adding new features.

-- Anonymous, November 21, 2000

My company's experimented with a few of the practices, and I've been using most of them in my home projects. Most of it's not natural at all for me - but it's very, very good. I've been doing better work and having more fun than I ever did before.

That said, you don't have to adopt all the practices, and you certainly don't want to adopt them all at once. Find your biggest problem and solve it.

A lot of people say that they'd hate programming in pairs all the time, and I understand the sentiment. At one time, I would have agreed with them. At my company, though, we had a terrible problem with our truck number - nobody understood anybody else's code. We'd actually had to tell customers that we couldn't solve their problem for a few weeks because the guy who understood that code was on vacation. Pair programming was an absolute godsend. Now, whenever we write code, we know that at least two people understand it, and that number increases pretty quickly as the pairs swap around.

Oddly enough, we didn't have to enforce the rule for very long - now people are pairing of their own free will.

I'm not saying that you should be pairing. I'm sure it isn't for everybody, and if you're getting by fine without it, great. But when you notice that you have a problem that one of the XP practices is meant to solve, try it out.

-- Anonymous, November 21, 2000

me again, on pair programming. All I can say is...
I love it. Wish I could do it more, unfortunatly when mgt see's deadlines, any sort of colaboration is seen as wasting time. ;(.
One of the big things I've observed get in the way of pair programming is when the ego of one member gets in the way of accepting the ideas of the other. I once worked with a 'contractor' mixed in with full time staff, this person was increadably arrogant & just would not accept the ideas that anyone else had. Probably felt he had something to prove, anyway not a good candidate for pair programming.

-- Anonymous, November 22, 2000

It is difficult and a long process to adopt the XP philosophy, especially programming in pairs. But, I've found that almost everyone is willing to accept a partner for some tasks. I have often sought a partner when trying out a new design, fixing a tricky bug, or when I need to transfer knowledge (the "brain dump") about a particular class, subsystem, or system

-- Anonymous, January 28, 2001

I have seen teams implement part of XP and then apologize to everyone because they know they're not doing it "the right way."

I see XP as a set of process patterns. Think of their practices just the same way you think of design patterns. Wouldn't you look at me strangely if I looked through your code (or design) and said "Well, I see an adapter, a decorator and several mediators but where are your visitors? This is an incomplete usage of design patterns!" You would think I was nuts.

We can't look at XP or the Unified Process (UP) the way we did with old methodologies, all-or-nothing. These newer processes are so much more flexible, we can use them in whatever ways they make sense. That means whatever fits the application, the organization, the people, their skills, etc.

The pair programming is usually the most contentious aspect of XP for everyone. I've actually never seen it done full-time like the XP books and Web sites describe. But, I've tried to take the best parts of XP, which for me are rapid iteration, massive communication, refactoring, continuous integration and the 40-hour week (yeah!!) and integrated them into my way of thinking.

I hope this doesn't come off as preachy, but I'm a process mentor so I guess I tend to be that way sometimes. Sorry if it's offensive.

Daryl Kulak Water-Logic, Inc. www.water-logic.com

-- Anonymous, February 25, 2001

Everyone is talking about Pair Programming and how it works great when used properly. I'd just like to mention another scenario where it doesn't work at all: when one of the pair thinks much faster than the other. I've often had people watch over my shoulder while coding and if I didn't slow down my normal coding cycle, they wouldn't know what's going on. (I've also been on the other end of things too lest you think I'm conceited in some way)

It has nothing to do with intelligence or a mismatch in understanding the problem domain. It's just that some people generate new ideas faster than others. So, be careful who you pair with when Pair Programming. A fast thinker will feel frustrated when paired with a slow thinker and vice versa.

Like everything else, there are good parts and bad parts to XP. Take what works for you and use it.

-- Anonymous, April 06, 2001

A fast/slow thinker pairing can be tricky. On one hand there's the opportunity for the fast thinker to be coaching the slow thinker, but on the other hand there are limits to how quickly people can aborb new teachings. (And new ideas, particularly paradigm-shaking ones, can throw people into chaos while until the ideas have been fully processed. Some developers spend much of their careers in this kind of chaos.)

On the question of adopting XP practices, I've found that these give good immediate payoff are:

• Program in Pairs. Two sets of eyes and two brains working on code keeps people from getting blocked, and elicits a lot more creative thought than two people working independently. And the cross- training benefits are wonderful, even at the level of best-practices for keyboard shortcuts.
• Defer functionality until you need it. Write only what you need, when you need it. Avoid generalizing prematurely. Worry about "use" before some imagined "reuse".
• Write unit tests first. Writing the test cases first forces people to think through their APIs up-front, rather than inventing a cool API and only later discovering that it has built-in impedance mismatches (or is hard to test). Having a good automated test harness is essential. It has to be push-button simple.
• Refactor. The meal isn't complete until the kitchen is clean.

I've incorporated these (save pair programming) into my personal work, and have been quite pleased with the results. The discipline of writing test cases first was a tough one, but the confidence you gain by being able to do a full regression test right now is wonderful.

-- Anonymous, April 06, 2001

[The discipline of writing test cases first was a tough one, but the confidence you gain by being able to do a full regression test right now is wonderful]

It's also extremely empowering, and it puts the *people* back in control of the software. It gives you the power to changes without the (fully justified) fear of breaking something somewhere. It lets you keep moving forward on a project, instead of degrading in to Analysis Paralysis once the project hits a certain level of complexity.

To anyone who has not worked on a project where they can re-run a sizable test suite *right now* anytime they want, I encourage you suspend judgement on anything XP-related until you experience this.

-- Anonymous, May 14, 2001