File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Pair programming sucks Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Pair programming sucks" Watch "Pair programming sucks" New topic
Author

Pair programming sucks

Damon Black
Greenhorn

Joined: Oct 10, 2007
Posts: 16
Originally posted by Lasse Koskela:

Agreed. People over process. Again, however, I've found XP and Scrum being much more "people over process" than any alternative I've seen.


I still think it's mostly a matter of temperament. For people who like to think out loud and thrive on constant interaction with others, XP feels like "people over process". For me it was the opposite.

Originally posted by Rusty Shackleford:
The problem with any process is that it is a one size fits all approach. What makes XP worse is that it is very rigid. One part fails, the project starts spiraling down.


Whether XP is supposed to be so rigid or not, I've seen it applied in exactly that way. All of my attempts to modify the process to work for me were rejected outright.
[ November 12, 2007: Message edited by: Damon Black ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Damon Black:
For people who like to think out loud and thrive on constant interaction with others, XP feels like "people over process". For me it was the opposite.


Having seen the most introvert developer I've ever met become a fan of pair programming and open team rooms, I seriously doubt that it's only about "liking to think out loud".


Whether XP is supposed to be so rigid or not, I've seen it applied in exactly that way. All of my attempts to modify the process to work for me were rejected outright.


I can imagine that, if that were my experience, I would probably also be quite skeptical of XP in general. After some thinking, I'd probably come to the conclusion that it was more a failure of the team to integrate my needs into the process. After some more thinking, I might come up with the idea that it was *me* who failed to influence the process in a way that was both acceptable to me *and* my teammates.

And finally I might decide that the corporate/team culture wasn't a good fit for me, and that it is good to have found out about that, so that I now have the opportunity to find a better fit. Whether that fit could include XP-style development would probably be still quite open, though certainly not as open as before.

But that's just me...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rusty Shackleford:

Certainly other factors not related to any specific process do contribute to a distracting environment, but the core of XP demands a distracting environment. This is why I think it is perfectly valid criticism of XP.


XP doesn't demand a distracting environment. Perhaps it demands an environment that can easily become distracting to you. Still, if distraction becomes a problem (and one that overshadows the benefits such as from Osmotic Communication), you need to do something about it. And doing something about it is not against the spirit of XP, as long as you earnestly try to make the modifications in the spirit of the values and principles of XP. I would even say that - as far as XP can do such a thing - it would demand you to do something about the problem.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rusty Shackleford:
Constant distractions, noisy environment, people looking over your shoulder. What a mess.


Yes, what a mess. That's not at all an description of a well functioning XP team, fortunately.

XP is NOT a natural way to do things.


There is nothing natural about programming a computer at all in the first place.

YAGNI is just code for 'I just wasted my time on something because of a lack of proper up front design, but I am going to pretend it is something postive'.


With the proper skill set, YAGNI doesn't cost time, it *saves* time. Let alone that it improves return on investment.


If you are constantly communicating, you are distracted by the task at hand.


Unless you communicate about the task at hand, I'd assume.

The problem with any process is that it is a one size fits all approach.


Well, but XP explicitly is *not* "one size fits all".


What makes XP worse is that it is very rigid. One part fails, the project starts spiraling down.


That's a common myth, but there are many teams out there that prove the opposite.

A shop that rigidly adheres to any process is not a shop worth working for. Whatever process you use must be tailored to fit the dynamic of the team and work to the strengths of the individual programmers. Otherwise you are just pounding a square block into a round hole.


Absolutely true.

On the other hand, you don't learn much about a process by not following it.

It's a puzzle...
Damon Black
Greenhorn

Joined: Oct 10, 2007
Posts: 16
Originally posted by Ilja Preuss:
...I seriously doubt that it's only about "liking to think out loud".


Agreed, it was about much more than just that. A fair number of XP's practice went against the grain for me.

After some more thinking, I might come up with the idea that it was *me* who failed to influence the process in a way that was both acceptable to me *and* my teammates.


Yeah... well it wasn't my teammates who fired me. They were actually quite accommodating. Regardless, I tried taking this on myself for two years, thinking all along that something was wrong with my approach or skillset that kept me from thriving in an XP environment.

I've heard it said that XP isn't for all programmers and I have to agree. Given the industry's limited experience adopting XP in broad fashion, I suspect it may yet turn out to be a poor choice for most programmers. But that's just a guess.

I'm still quite open to the spirit of Agile and XP, though more cautiously. I don't think any methodology is perfect, and XP is no exception. The one thing I will seek to avoid is any shop that assumes that their pet methodology answers all questions, especially if its every breakdown is blamed on 'operator error'.
[ November 12, 2007: Message edited by: Damon Black ]
Rusty Shackleford
Ranch Hand

Joined: Jan 03, 2006
Posts: 490
Agile principle are fantastic, but XP just takes things way to far.


"Computer science is no more about computers than astronomy is about telescopes" - Edsger Dijkstra
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Rusty Shackleford:
Agile principle are fantastic, but XP just takes things way to far.


Too far - for what?

Too far to feel comfortable to you? Granted.

Too far to be able to work quite successfully? Obviously not.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Rusty Shackleford:
Constant distractions, noisy environment, people looking over your shoulder. What a mess.


Having worked in many, many different environments, I've realized that there are lots of dumb ways to do things. It's easy to decide on something that seems ok, but quickly reveals itself to be a dumb mistake. Such as, putting three disparate teams into a single crowded project room. Or putting people into giant cube farms with floor-to-ceiling walls, so high that no one can see anyone else or see anything going on.

Most recently I was working in a shared area, a team room. The only problem is that we weren't really a team--we were a set of mentors who were each helping out on (OO design, programming, agile, TDD, etc.) problems across a different handful of projects. There was certainly a lot of value in being in the shared space--I learned some extremely valuable things that I might never otherwise have learned.

But, it was distracting. It wasn't until I started bringing up some of the developers that I was mentoring into that shared space that I realized pairing was a great way to remove the distractions. Once we started working on a problem, the distractions that had seemed constant before disappeared--our focus was on the problem, and other people tend not to bother two people that are obviously engrossed in something.

I'm not sure you need a coach to figure things like this out, but it helps to have people who can help you avoid the pitfalls that are fairly easy to step in.

Opinion time:
No one talking, can't find the people you need to talk to, lots of useless meetings, lots of time spent doing useless documents. What a mess. :-)

Jeff


Books: Agile Java, Modern C++ Programming with TDD, Essential Java Style, Agile in a Flash. Contributor, Clean Code.
Jeff Langr
author
Ranch Hand

Joined: May 14, 2003
Posts: 762
Originally posted by Rusty Shackleford:
XP is NOT a natural way to do things. That fact you need a coach is proof of that.


A coach is a good idea with any new unknown, and it's also a great idea for figuring out to get a team to work together well. If an agile team were transitioning to waterfall or RUP for the first time, I can guarantee they would think most of its ideas were unnatural. An experienced coach would also expedite the transition and save lots of effort that would otherwise be wasted--such as the effort to determine what the specific instantiation of RUP should look like.

YAGNI is just code for 'I just wasted my time on something because of a lack of proper up front design, but I am going to pretend it is something postive'.


It's unnatural to make a considerable effort in up-front design and then assume that (a) it represents the best way to solve the problem, (b) requirements won't or haven't changed, and (c) even if things haven't changed in the year that it took to deliver a system based on that perfect up-front design, that it can cover all eventualities after the initial system deployment.

I don't use the "YAGNI" phrase much, but I do believe that learning how to do anything other than deliver a system incrementally is folly in most of today's marketplaces. Show me a better process that supports this, and I'll follow.

Jeff
 
 
subject: Pair programming sucks
 
Similar Threads
Is pair programming practical
Agile Software Development: True Adoption or Just a Label?
Extreme Programming in Russian
Quartet Programming
blog of Kathy - Pair Programming is NOT always a choice