Fog Creek Software
Discussion Board




XP is wearing no clothes

I think XP is a classic case of the Emperor wearing no clothes. Most of its tenets are nothing more than good practice, and most have the feel of the lessons of someone's first successful development project.

I dislike XP because it is exclusionary; the use of new jargon words such as Refactoring to describe existing practices is a classic social technique to exclude non-members from a group.

Pair programming is all about requiring people to work together in a certain way. It's not necessary, and the compulsory nature of the requirement is something I find offensive. People in a team work together as required. There's no need to change that.

I think the big reason for XP's popularity is that it strokes the egos of senior developers; that is, the people who decide whether to implement XP.

Contrary to the ego-less claims of XP, I think Pair Programming creates a strong hierarchy in which more senior developers receive positive rewards, and since they decide whether it's good, that's sufficient to carry the movement forward.

I notice proponents adapt their definitions of XP on the fly to include everything their audience considers good, and to reject the bad.

Just my view. I'm sure others will give me their views.

Hugh Wells
Tuesday, May 07, 2002

>Most of its tenets are nothing more than good practice

That's the idea. It takes existing practices to an extreme level. If testing is good then test all the time. If integration is good then integrate continously.


>I notice proponents adapt their definitions of XP on the fly to include everything their audience considers good, and to reject the bad


One of the other main concepts of XP are to throw away pieces that you don't need. Agile methods are basically methods that allow the teams to be flexible and pick and choose from what works for them in their environment. It's not a rigid methodology outlined in a 4 inch binder collecting dust on the shelf. If something doesn't work, disgard it.


Have you used XP? And if so are you totally against pair programming in all situations or just certain ones? I myself like to program alone but I also sit down with my partner and code together through tough areas or problems that arise. I see the most value in those situations. I pick and choose from XP taking what i want and leaving what I don't.

Ian Stallings
Tuesday, May 07, 2002

Ian, nice response. I've got nothing against working together; I train graduates and I work with colleagues. The issue is the forced pairing and the mechanism, which strikes me as Taylorist.

Taylorism refers to the regimentation of factory workers that marked the start of the industrial revolution.

Also, I mean, so what's NEW about XP apart from the jargon? (And consulting fees?)

Hugh Wells
Tuesday, May 07, 2002

XP is good insofar as it takes 20 year old software
engineering principles and successfully markets them
to the PHBs.

Johnny Simmson
Tuesday, May 07, 2002


That sounded like a mission statement (ie, lot of buzzwords and at least one acronym in a very short sentence.)

Leonardo Herrera
Tuesday, May 07, 2002

Hugh,
XP has a lot of rules but rules are made to be broken. If you find that pair programming doesn't work then throw it away.

http://www.extremeprogramming.org/rules/fixit.html
http://c2.com/cgi/wiki?TheyreJustRules


Not to say that the rules should be disgarded by one idividual but not by others, but the organization as a whole should decide what works best for them and bend it to suit their needs. No one is gonna stick a gun to your head and force you to use pair programming in inorder to get "XP certified". I look at XP as a set of guidlines or recommendations that I can use or not use. I like to use CRC cards to divide up tasks and create user stories. But I also like to create UML models to describe the system design.

Try to see past the hype (which I admit seems to be growing) and take anything you need. I wouldn't force anyone to use a method that doesn't work for them. Productivity and value are what we all strive for as developers and managers alike. I never paid one dime for a XP consultant but I did buy one small book. Fortunately I got the XP experience when I started working for a company three years ago and walked away from it having solid coding skills that I can take with me into other organizations, regardless of the methods they use. Anything that can make my code better and help my productivty I keep, all else is disgarded.

Ian Stallings
Tuesday, May 07, 2002

Ian, but doesn't this get back to the Emperor has no clothes. XP is anything you want it to be. So what is it? Is it anything? This is the way cults operate.

Hugh Wells
Tuesday, May 07, 2002

>>>"Taylorism refers to the regimentation of factory workers that marked the start of the industrial revolution."<<<

Interesting that you mention Taylor.  The industrial revolution had been around a century or so when Frederick Taylor came along at about the beginning of the 20th century to introduce scientific management.

The concept of Taylorism has been floating around in my head the past few weeks when I think about the problems of software engineering.  He was a leader in the promotion of the idea of the professional manager and did time and motion studies.

I have had a suspicion that a lot of the problems software engineers deal with are due to working in an environment where managers still think in the style of the production management environment of Taylor's era.

Thus we get such things as "software factories", an idea popular a few years ago where software would be produced production line style, no thinking necessary; big-M Methodologies, another way to eliminate thinking; cubicles, where the needs of the developer to type entries on a keyboard are well taken care of cheaply, no need for thinking on the job; etc.

XP may promote some common good software engineering practices, but I am concerned that the features that will be most attractive to managers are things like the pair programming in a bullpen environment.  That is, the features that make it look like you can grind out code like a production line.

mackinac
Tuesday, May 07, 2002

Yes, that's the thought that occurred to me. How does Pair Programming differ from working together? Answer: it's a mandatory part of the process, and no doubt will sooner or later be mandated by dills.

Hugh Wells
Tuesday, May 07, 2002

>>>"One of the other main concepts of XP are to throw away pieces that you don't need."<<<

Ian,

How much can you throw away and still call what you are doing XP?

A significant fraction of the features of XP, such as unit testing, acceptance testing, etc., are taken from more traditional software engineering practices.

If you give up pair programming (all the time, occasional pairing or just doing code reviews doesn't count), or some of the other features that are more distinctive of XP, do you have any reason to still call it XP?

mackinac
Tuesday, May 07, 2002

Note: I'm not Ian.

>>Ian, but doesn't this get back to the Emperor has no clothes. XP is anything you want it to be.<<

No, it's not anything.  XP is made up of two elements:

1) A set of development principles, of which you can choose any one of that set.  (At least, this is what I understand from a brief read of the original book and some online research.)  These principles include pair programming, iterative development, coding unit tests first, etc.  I won't try to provide an exhaustive list, but here's a good one:

http://www.extremeprogramming.org/rules.html

Some of these rules are time-tested advice.

2) A mindset about development.  That mindset emphasizes strong dedication to the development process, improving existing practices and trying new ones.  This is the religious side of Extreme Programming, where people become fanatical about producing bug-free code that meets customer needs.

From my perspective, XP is mostly about raising the standards for software development.  XP proposes very high standards, and the ruthless application of practices that can radically improve the development process.

However, every workplace and circumstance is different, and not all of this advice is guaranteed to be effective everywhere, which is why XP has its "do not hesitate to change what doesn't work" rule.

So, XP is not "anything."  It's a set of practices -- some of them certainly well-known, but not necessarily applied in all cases -- and a commitment to being extreme if need be to improve the development process.

Brent P. Newhall
Tuesday, May 07, 2002

"How much can you throw away and still call what you are doing XP?"

Why do you seem to be more worried about what you call it than you are about whether what mix you pick delivers. I think arguing over a formula to decide how much of a methodology you embrace and how much you can ignore before its not that methodology any more but something else has got to be a good definition of "futile".

Will your CEO ask "Are you keeping it real" or will they ask "Does it deliver results"?

Robert Moir
Tuesday, May 07, 2002

Again, the Emperor is wearing no clothes. I think XP is best viewed as a socio-cultural phenomenon, and as a marketing phenomenon.

The socio-cultural comes in explaining why it's gained the traction it has. Partly, I think that's because it reinforces team leader grade management. Partly, also, it satisifies a desire for professional mystique among new programmers.

The marketing phenomenon lies in the in significant book sales and seminar fees.

Hugh Wells
Tuesday, May 07, 2002

A few responses rolled into one:

Hugh:
>Ian, but doesn't this get back to the Emperor has no clothes. XP is anything you want it to be. So what is it? Is it anything? This is the way cults operate.
><snip>...and no doubt will sooner or later be mandated by dills.

Mackinac:
>XP may promote some common good software engineering practices, but I am concerned that the features that will be most attractive to managers are things like the pair programming in a bullpen environment. That is, the features that make it look like you can grind out code like a production line

phew, I can sense just a little resentment for management in your statements ;-)  Managers need to understand that it is a development process, not a silver bullet. No development method in the world can fix a broken management process. We as developers need to communicate this to them.

As for sitting in cubicles grinding out code in a production line-like fashion..well that happens now. I've been in large software shops where hundreds of developers sat in cubicles going over bug lists with hundreds of entries, using assembly line production styles.

I'm not sure how much you can throw away and still call it XP and honestly I don't really care. I'll call it solid gold when it's done and bug free. My religion is software not methodologies. There is no silver bullet methodology that every team in the world can apply and get the good results. Teams and leaders need to apply what they think works best for them and adjust what doesn't work as needed. I don't tout XP as the end all be all in development, but it certainly is moving in the right direction.



Brent:
Excellent summation of XP! Particularly the mindset part. I think that's the most important thing I carried away from my experience with XP developers. The dedication to creating solid software that met the client's needs and the willingness to do anything to reach that goal, however "extreme".

Ian Stallings
Tuesday, May 07, 2002

The phrase 'emporer has no clothes' seems like a provocative exageration.  It suggests there is nothing at all behind XP.  XP may sound a bit like 'accepted' practices but I don't know many shops that do daily builds which run automated unit tests of *every* class and every method. 
In fact I had never heard of such a thing before XP -- as in 'what? write a test for every method????"

Your experience may differ but XP is the only method I know of that puts unit-testing at the center.  Software is invisible -- there is no way to look at source code and determine if it's finished or not.  Code reviews and UML diagrams are nice but they don't really prove anything.  The only proof a feature works is a test. 

I'm with you on the hype though.  XP has its zealots, just like Java, XML, etc.  Be sceptical, but be curious.

IanRae
Tuesday, May 07, 2002

I think to a certain extent XP is the "sane man's" reaction to the other software development Methodologies (such as RUP) being espoused by people whose goal is to turn  all programming work into assembly-line labor.

No capital-M Methodology is going to replace common sense and competence, experience and thoughtfulness.  All of those attributes are required in order to be able to truly innovate.

Anca Mosoiu
Tuesday, May 07, 2002

From the responses here, looks like Hugh was right that nobody agrees what XP is, just that it's COOL!

Pair programming is the only unique characteristic of XP, and I *really* don't understand what causes people to get excited about it. Are you slow and hope the other guy will pull your slack? Too lazy to walk to the next office when you have a question? Can't afford a computer for all your programmers?

I'm willing to accept that two programmers at one desk would probably be faster than one - but not faster than two programmers at two desks. The one place this makes sense to me is if you have a lot of money to burn, you could just hire twice as many programmers and avoid some scaling problems - sort of like a simplified version of Fred Brooks's surgical team example in the mythical man month.

b
Tuesday, May 07, 2002

"How much can you throw away and still call what you are doing XP?"

Adapting XP is seen as a three step process by most proponents:

1) Do everything as written.
2) After having done that, experiment with variations on the rules.
3) Eventually, don't care if your are doing XP or not.

See also http://www.xprogramming.com/xpmag/PracticesForaReason.htm and http://www.xprogramming.com/xpmag/are_we_doing_xp.htm

Ilja Preuß
Tuesday, May 07, 2002

"I'm willing to accept that two programmers at one desk would probably be faster than one - but not faster than two programmers at two desks."

Sounds reasonable - but interestingly completely contradicts my experience...

Ilja Preuß
Tuesday, May 07, 2002

Pair programming is all about code reviews.

Code reviews are a well known best practice, that when diligently done, results in more robust software with fewer bugs. Studies have been done to verify this - I think Code Complete talks about this in some detail.

So, going with the "Turn the knob up to 10" philosophy of XP - if some code reviews are good, always code review all the time. Pair programming is just the way that you always get more than one pair of eyes on a chunk of code all the time.

If you've never had the experience of staring at a chunk of code for hours and having it stubbornly refuse to work, only to have somebody else walk in the door, say "here's the problem" in 15 seconds and make you feel like an idiot, you aren't a real programmer - or at least you haven't had any professional development experience yet.

I personally haven't had much experience with pair programming - never had the right environment. Pair debugging, however, is something that I've done repeatedly, and it works. I've had orders of magnitude improvements in bug fix time just from having that other person in the room.

Don't mock it until you've tried it.

Chris Tavares
Tuesday, May 07, 2002

"If you've never had the experience of staring at a chunk of code for hours and having it stubbornly refuse to work, only to have somebody else walk in the door, say "here's the problem" in 15 seconds and make you feel like an idiot, you aren't a real programmer[...]"

Even more often it happens to me that I hear myself say to that somebody "Do you have some time to look at this - I am really stuck here. Look, this is supposed to do that, but does do that other thing... DUH, forget it, just found the error. Thank you very much for listening to stupid me..." %-)

Ilja Preuß
Tuesday, May 07, 2002

I have the feeling I'm responding to a troll, but what the heck...

There are two kinds of XP.  There is the "fad" XP, where you latch onto the XP "phenomenon" to justify something you'd like to do anyway.

Then there is XP, the well-designed, integrated philosophy, where every piece supports every other piece and there is NOTHING that you can "take out" and still have it really be XP.

I admire the latter XP, as a beautiful example of a well-designed agile methodology.  I don't *use* it, mind you, as my environment isn't appropriate for it, for a variety of reasons.

I *do* however, do agile development.  My team has its own set of mutually supporting practices.  This set of practices certainly has overlaps with XP practices.  But I don't call it XP.  It's not.  If you're not *at least* doing pair programming and unit testing for all features, it's not XP.  Look it up.  It just ain't.

XP is a team methodology.  And it requires a lot of things to make it work.  Not the least of which is that all your developers care about your customer and about producing good results *more than* they care about their personal convenience or ego.  Many of the comments here about pair programming are correct, but only in relation to an environment where nobody gives a crap.  I have never worked in such an environment - I only work for teams where the culture is good or where I'm there to create a new team, which I can build a good culture into from the start.

In a good culture, pair programming by itself can produce near-miraculous results.  Those results, however, are NOT SUSTAINABLE WITHOUT THE OTHER XP PRACTICES.  If you have code ownership, how can you pair?  If you don't unit test, how do you know you didn't break it?  And so on.

XP is *not* a mix-and-match keep-what-you-like and toss the rest system.  If you don't believe me, check the book "Extreme Programming Explained", where IIRC it explicitly says, "If you're not doing unit testing, you're not doing XP.  If you're not doing pair programming, you're not doing XP."

Phillip J. Eby
Tuesday, May 07, 2002

Well, I guess that settles it then.  I'll never do XP.  As the French said when GE bought their medical equipment business:

"the last person that made us wear uniforms was Hitler"

This engineer has never submitted to dictatorial nonsense of any sort, no matter how sweet the stock options...

You show me an objective metric (objective in the scientific sense meaning verifiable and repeatable by an independent party) which can quantify the productivity & quality gain claimed by pair programming, I'll be all for it.

Until then, forget it.

Nat Ersoz
Tuesday, May 07, 2002

"""You show me an objective metric"""

Has there been a survey as to the methodology employed
by level 5 organizations?

Johnny Simmson
Tuesday, May 07, 2002

I think most people are missing the point, that XP is mostly a way to sell books, consulting, and conference appearances. There are some interesting ideas in the books. Not sure what the big deal is.

stating the obvious
Tuesday, May 07, 2002

Phillip J. Eby's comment is easy to misunderstand as being pedantic.  But most anecdotes against XP come from people who didn't actually use XP -- they used some bastard version of it that was more politically motivated than by quality.

Anecdotes tend to leave out all the entertaining details.

Anon
Tuesday, May 07, 2002

This REALLY IS an interesting socio-cultural phenomenon. Many of the quotes from XP proponents above are verbatim quotes from apologists for Communism and various cults. Probably fascism too.

Hugh Wells
Tuesday, May 07, 2002

Phillip J. Eby makes some interesting comments:

>>>"There are two kinds of XP. There is the "fad" XP, where you latch onto the XP
"phenomenon" to justify something you'd like to do anyway."<<<

I noticed that.  It's sort of like religion. This has caused some frustration to those of us none XPers trying to get an understanding of what it is.


>>>"If you're not *at least* doing pair programming and unit testing for all features, it's not XP."<<<

This is the impression I have from reading the web sites, but some posters have other opinions.

>>>"Not the least of which is that all your developers care about your customer and about producing good results *more than* they care about their personal convenience or ego."<<<

Does there have to be a conflict?  And how do you compare these things if you can't put a numeric value on them?  At one time I worked in an environment where the idea of producing good results was one of the things that made it a great place to work.  I think we did good work.  Some of that software is still in  use after 10-15 years.

But I have worked in environments where I dreaded going to work in the morning.  And I know people who can tell you how many years, months and days they have till retirement.  I don't want to be in either one of those situations.  While pair programming could be productive, the descriptions make it sound like it would be extremely stressful.


>>>"Many of the comments here about pair programming are correct, but only in relation to an environment where nobody gives a crap. I have never worked in such an environment - I only work for teams where the culture is good or where I'm there to create a new team, which I can build a good culture into from the start."<<<

You'll have to tell us how you find such environments - but that is a topic for another thread.

>>>"In a good culture, pair programming by itself can produce near-miraculous results."<<<

Is it the pair programming or the good culture that is responsible for the results?

mackinac
Tuesday, May 07, 2002

>>>"Many of the quotes from XP proponents above are verbatim quotes from apologists for Communism and various cults."<<<

This would be more interesting if you gave some examples of which quotes you're referring to.  I did not happen to recognize any myself.

mackinac
Tuesday, May 07, 2002

"So, going with the "Turn the knob up to 10" philosophy of XP - if some code reviews are good, always code review all the time. Pair programming is just the way that you always get more than one pair of eyes on a chunk of code all the time."

Why not turn the knob up to 11 then and put all the programmers on one computer? :)


"If you've never had the experience of staring at a chunk of code for hours and having it stubbornly refuse to work, only to have somebody else walk in the door, say "here's the problem" in 15 seconds and make you feel like an idiot, you aren't a real programmer - or at least you haven't had any professional development experience yet."

I'm the guy that walks in the door and solves the problem in 15 seconds.  I don't want that other guy in my office bugging me all day!


Maybe I've been thinking about this wrong. It could be if you take two mediocre programmers and bolt them together you could get one average programmer - this would be a good thing since mediocre programmers are easy to come by. I don't think it would work with two good programmers though, since they would both know what to do and the other guy would just sit there and agree, "yeah that looks good, yeah that too.."

I was working with a junior guy in my office today and it was actually kind of annoying. Normally when I'm typing in code I'll keep track of syntax mistakes I've made and go back and fix them after typing in the meat of the code so I don't lose track of the design. The junior guy kept trying to help by pointing them out, so after awhile I just started fixing them before he noticed them, which made me keep losing my place in the code!

b
Tuesday, May 07, 2002

I concur with "b". Pair programming is "extremely" annoying when you have someone good paired with someone bad.

That said, You have to look at where the extreme guys are coming from in order to truly understand XP and pair programming. They build extremely boring systems for GM and other car companies. I have been in a situation like this before, and it sucks to a serious extreme.

Thus, "pair programming" can alleviate some of the extreme ennui which occurs when building these systems. Instead of coming into work extremely dreading another day of dealing with extremely tedious crap, you come into work, and it is ok, because at least there is another dude there sharing your burden. Now, this can be an extreme nightmare if your pair programming partner has extremely bad breath, but if he's a decent chap, it makes the time fly by a lot quicker.

The REAL motivation behind "extreme programming" is an attempt to turn "extreme"ly lame work into something a bit more tolerable.  I doubt it needs to be implemented where people don't hate their jobs... YMMV

extremely bored
Tuesday, May 07, 2002

>>>"Now, this can be an extreme nightmare if your pair programming partner has extremely bad breath, "<<<

While extremely bored just seems to be trying to be extremely clever, s/he has a significant point here, not just concerning halitosis, but BO, too.

I have known a few people whose most memorable characteristic was their odor, including one guy who gave off such an incredible stench that just being in a room that he had walked through was a sickening experience.  Imagine having to sit close enough to such a person to see the same computer monitor all day, every day.

mackinac
Wednesday, May 08, 2002

"The REAL motivation behind "extreme programming" is an attempt to turn "extreme"ly lame work into something a bit more tolerable. I doubt it needs to be implemented where people don't hate their jobs..."

Sorry, but that's just silly. I started trying pairing on a hobby project (a game). I love it. I will *always* try to pair as much as possible regarding the circumstances.

Ilja Preuß
Wednesday, May 08, 2002

>>I don't think it would work with two good programmers though, since they would both know what to do and the other guy would just sit there and agree, "yeah that looks good, yeah that too.."<<

That is far away from what happens in my experience. Did you try it?

Ilja Preuß
Wednesday, May 08, 2002

"I was working with a junior guy in my office today and it was actually kind of annoying. Normally when I'm typing in code I'll keep track of syntax mistakes I've made and go back and fix them after typing in the meat of the code so I don't lose track of the design. The junior guy kept trying to help by pointing them out, so after awhile I just started fixing them before he noticed them, which made me keep losing my place in the code!"

There is a simple fix to this: Let the junior type for the most time. It works for me.

Ilja Preuß
Wednesday, May 08, 2002

"Why not turn the knob up to 11 then and put all the programmers on one computer? :)"

Well, for some tasks triple or quadruple programming in fact might be effective - but only for a short time in my experience. The overmoduldation can get exhausting... ;-)

Ilja Preuß
Wednesday, May 08, 2002

The posts above are kind of funny. Comparing what I've said to communist apologist is just a troll.

No one is forcing you to use XP, certainly not me. I advocate good practices plain and simple. I do not care what they are called, if I am using the "official" XP, or what Kent Beck or anyone else says. Good practices are just that, good practices.  If they don't work for you or you disagree with them it doesn't disqualify their usefulness.

Ian Stallings
Wednesday, May 08, 2002

"There is a simple fix to this: Let the junior type for the most time. It works for me. "

I guess by saying "junior guy" I confused the story with too much detail. This guy is a really good programmer, he's just trying to be helpful.

As far as having the other guy type:
1. I would probably just do the same thing and comment on his mistakes. :)
2. He's a programmer, not a secretary.

My point is that "Pair programming" is helpful if the actual act of programming is difficult for you, but kind of tedious if you both know what you're doing.

I think there's also a spectrum to the kind of programming people do - on one side you are doing something fairly simple, but you have to wade through a lot of system documentation, unfamiliar libraries, compiler etc. On the other side, you have some tricky algorithm you're trying to implement and you're very familiar with the tools you're going to build it with. In the first case, working with another programmer is great because you can help each other figure out what's going on. In the second case I think it just gets in the way and breaks your concentration.

We try to do as much as possible of the second case where I work, which might be why I don't see much value to Pair Programming.

b
Wednesday, May 08, 2002

one other thing semi related to "b"
if you seem to be doing ok, is there any reason to try out XP or pair programming?

when i was working on e-commerce systems i could have definately used something like XP, because I hated that kind of work, and having some serious methodology and a programming partner would have made it a lot easier to slog through it.

however now i'm doing OSX development for a research team and am having a lot of fun. i have zero problems getting up in the morning. i crank out code like no one's business. my company loves me.  will XP make my life even better?

extremely bored
Wednesday, May 08, 2002

>>>"We try to do as much as possible of the second case where I work, which might be why I don't see much value to Pair Programming."<<<


There have been a lot of interesting (as well as silly and useless) comments on XP and pair programming in these threads the past few days.  When it started out I thought that pair programming would be something that would not fit well with the kind of development work I do and I probably wouldn't like doing it.  After all this discussion I haven't changed my mind about that at all.

Maybe, like b, this is due to the type of development that I do or perhaps most of my work has been in an environment that was good enough that pair programming wouldn't have helped much.  But if I worked in the Dilbert zone I might think of it as at least a partial step out.

I had considered reading an XP book, but at this time I think I'll go back to studying more traditional methods. If I have some spare time I might still read through an XP book.

I do have some concern that I'll run in to a manager who thinks that XP is the silver bullet that Brooks says doesn't exist, the big-M Methodology that will eliminate the human factor in software development.  Then I'll start sending out my resume.

mackinac
Wednesday, May 08, 2002

>>I do have some concern that I'll run in to a manager who thinks that XP is the silver bullet that Brooks says doesn't exist, the big-M Methodology that will eliminate the human factor in software development.<<

I'd be *very* scared if I heard that, since from what I've read, the human factor is what XP is all about.

Brent P. Newhall
Thursday, May 09, 2002

>>>"I'd be *very* scared if I heard that, since from what I've read, the human factor is what XP is all about."<<<

Interesting that we read the same things and come up with opposite interpretations.

I see common code ownership and, especially, pair programming as ways to eliminate the effects of individual judgement in the development process.

Pair programming gets you half way to the software factory concept.  You aren't at the point of routine manual labor, but all decisions are made by committee.

mackinac
Thursday, May 09, 2002

>>I see common code ownership and, especially, pair programming as ways to eliminate the effects of individual judgement in the development process.<<

Interesting.  I see Pair Programming as a way of increasing the amount of judgment levied against a particular piece of code.

The point of PP is to increase the number of development issues that are covered by the development person or team.  One person won't notice all the things that are or could be wrong with a piece of code.  Two people will notice more problems.

Sure, there's little or no *individual* judgment in Pair Programming, but that doesn't mean that the human element is removed.

>>Pair programming gets you half way to the software factory concept. You aren't at the point of routine manual labor, but all decisions are made by committee.<<

I don't see how this is at all similar to the factory model, though my perception of the factory model may be different from others' views.  Routine manual labor assumes a process that is completely solved.  Pair Programming is predicated on the belief that the problem is so difficult that it needs to be tackled by experts, and that one expert isn't enough.

Or, maybe I'm completely mis-interpreting things again.

Brent P. Newhall
Thursday, May 09, 2002

Hmm, they should opensource that 1st XP book and put it online, separated into Chapters so people can print it out for bathroom reading.

I often forget that my first coding experience was in pair programming mode.  It is a very spontaneous way of coding, but coder mythology turns programming into a loner staring in the dark at a computer screen, fighting the good Fight.

But I'm not necessarily advocating XP, because someone might threaten me by saying he Won't read the book because my arguments are so weak.  Ok then, don't. ;-P  When people show such an internal resistance, instincts are telling them something...

Sammy
Thursday, May 09, 2002

Pulled from http://c2.com/cgi/wiki?XpIsaPseudoMethodology:

There is a lifecycle model called "Evolutionary Prototyping". It has been around since the 80s (at least), and is common in the Smalltalk community.

Researchers who have studied the EP model have found benefits. The book "Wicked Problems, Righteous Solutions", for example, published in 1990(!) talks about those benefits. The Construx Software web site lists EP as a Best Practice.

http://www.construx.com/cxone/EngineeringProcess/Lifecycles/CxBest_EvolutionaryPrototyping.pdf (PDF, but Google has cached it as HTML.)

Both texts also talk about drawbacks and risks of EP. WPRS mentions "less documentation", "less coherent design", and "lower in extensibility" as drawbacks, but feels that EP with real documentation would be "an authentic paradigm".

Beck et al. attempted to fix these problems during the C3 project by requiring other activities during the lifecycle, including refactoring and tests for design and extensibility; user stories, pair programming and refactoring for documentation. (It is interesting to list the WPRS's bullet points for needed EP documentation: cleaned-up code, adequate commenting, explicit data structure, large routines decomposed, adequate user and maintenance manuals.)

rwh
Thursday, May 09, 2002

Nat:

>>You show me an objective metric (objective in the scientific sense meaning verifiable and repeatable by an independent party) which can quantify the productivity & quality gain claimed by pair programming, I'll be all for it.

Until then, forget it.<<

Dr. Laurie Williams, a professor at N.C. State, has been doing just that sort of research:

http://collaboration.csc.ncsu.edu/laurie/research.htm

Here's one blurb from an IEEE Software article (also at the above link).

"In 1998, Temple University professor
John Nosek reported on his study of 15
full-time, experienced programmers working
for a maximum of 45 minutes on a challenging
problem important to their organization.
In their own environments and with
their own equipment, five worked individually
and 10 worked collaboratively in five
pairs. The conditions and materials were
the same for both the experimental (team)
and control (individual) groups. A two sided
t-test showed that the study provided
statistically significant results. Combining
their time, the pairs spent 60% more minutes
on the task. Because they worked in
tandem, however, they completed the task
40% faster than the control groups, and
produced better algorithms and code."

Williams had similar positive results in her tests on CS students.

Sure, it's just a few studies, but more are being done, and they keep reproducing the results.

I find it interesting point that nearly all the studies mention that the programmers, especially the pros, are initially hostile to pairing, but after TRYING it for themselves and seeing the results, they like it.

John Lindsey
Friday, May 10, 2002

"if you seem to be doing ok, is there any reason to try out XP or pair programming?"

Besides being curious about wether you could do even better, I can't think of any... ;-)

Ilja Preuß
Friday, May 10, 2002

"As far as having the other guy type:
1. I would probably just do the same thing and comment on his mistakes. :)"

Are you saying you both are always having the same ideas? Wow...

"2. He's a programmer, not a secretary."

He is not supposed to only type, but to think, reflect, ask questions and even dissent. His partner is not meant to dictate, but to guide.

With other words: if one of the partners simply acts mechanically, pair programming certainly doesn't give you any advantages...

"My point is that "Pair programming" is helpful if the actual act of programming is difficult for you, but kind of tedious if you both know what you're doing."

That is not my experience.

Ilja Preuß
Friday, May 10, 2002

>>>Here's one blurb from an IEEE Software article<<<

The quoted article does not seem to support the claims of XP advocates.  XPers claim, if I understand correctly, that two developers doing pair programming are as productive or more so than two developers each working alone.

If that works, then the total time for the pairs should be the same as for the individual programmers.  In the study reported on here, the pairs took 60% more developer time to accomplish the same task.

Time to completion was less for the pairs, so if that was more important than cost and the tasks were indivisible, pair programming would be a good idea.  The higher quality might make it worth the cost, but that is not quantified.

This research leaves more questions than answers:
- How were people paired up?
- Why was productivity less than claimed by XPers?  Even though I have doubts about XPers claims, I didn't expect productivity to be this low.
- What was the developers normal work environment like?  DeMarco and Lister showed with their Coding War Games that work environment has a big effect on productivity. Would pair programming work differently in a high vs. low quality work environment?
- What happens if you scale up the project schedule from 45 minutes to 8hr/day 5day/week for 6 months to 2 years.

mackinac
Friday, May 10, 2002

I am going to make the unsupported statement that pair programming is unsuited to programming which requires lots of "discovery". 

Beck even states something like this "XP Explained" by noting that when exploring new or undesigned territory, he goes off and runs tests on his own (singular programming) and then once he undersands a concept, throws away the discovery work and then pairs up.

If your work involves lots of discovery, then PP may be a complete waste of productivity.  So, how is discovery defined?  I'm guessing programming in subject matter for which either you or your team have little experience.

Well, his dog won't hunt.  Most experiences are new for me, and I've been an engineer for 19 years.  10 of those most recently doing software,  Every time I get new hardware, its discovery.  Mostly, I write drivers - sometimes the layer up from a driver, like JNI code.  But mostly I sit near hardware.

But hey, you MSFT followers, like every week is discovery for you, because MSFT keeps cranking out some "new technology".  Some new paradigm in software engineering that renders all others obsolete.  Lemme count the ways:  Win16, Win32, DDE, OLE, OLE2, COM, DCOM, ActiveX, now C# & .NET.  Wow, no wonder I'm slow...

Oh yeah, this was about discovery.  The art/challenge of engineering is not in the syntax or mode (just give me some kinda posix wannabe, that'll do fine), but about the subject at hand:  Avionics, multimedia, switching/networking, simulation, etc.  The hard part is the subject matter, not writing the code.  And no matter what, it always seems that the subject matter is always new.

So, there ya go...  discovery is not conducive (sp?) to PP.

Nat Ersoz
Friday, May 10, 2002

>>>That is not my experience. <<<

Ilja,

You are one of the few people making comments who has experience with pair programming and likes it.  Could you give some description of your experience?

How was pair programming scheduled on your projects?
- Short term: how many hours per day or week?
- Long term: How many weeks pair programming?
- Relative: How much time not doing pair programming?

What is your comparative experience with projects that use individual programming?
- Environment: Cubicles, bull pen, offices or what??  Noise level and distractions?
- Management quality?

mackinac
Friday, May 10, 2002

From what I've understood, XP does not advocate *exclusive* Pair Programming.  The articles I've read have stated that individual development time is unquestionably useful, and that individual development should be a significant portion of the development effort.  It's just that most of your time should be spent pair programming.

Also, just because people tend to go off on their own to discover things, doesn't mean that two people can't share in a voyage of discovery.  "Pair Discovery" may simply be a practice that people haven't gotten used to yet.

Brent P. Newhall
Friday, May 10, 2002

And what kind of software were you developing?

mackinac
Friday, May 10, 2002

In XP, all production code must be pair written.  That's what the book says.

Nat Ersoz
Friday, May 10, 2002

>>In XP, all production code must be pair written. That's what the book says.<<

Okay, my fault.  I thought the idea was that it all had to be at least closely reviewed with your partner, with code written away from the partner kept to a minimum.

:shrug:  I'm learning as I go, here.

Brent P. Newhall
Friday, May 10, 2002

Assumption 1: the team has to own their own process
Assumption 2: most teams don't (yet) have the experience to choose practices based on experience

Conclusion: If I'm coaching a team, and they ask me how to improve, I ask if they have tried the basic practices. If they haven't, I suggest they try them. If they have, we can have an informed discussion.

Pair programming, in particular, is a practice lots of teams have not tried, and are extremely reluctant to try. Most teams I've coached, once they try it, would never go back. One team noticed that in 5 months the only bugs that got through the test suite and were reported later were all, all, coded solo. After noticing this, they made up their own rule about pairing on production code.

Note that I'm not saying that if you don't pair program on production code you are bad, I'm saying you should be able to choose from experience and not from predjudice.

Kent Beck
Friday, May 10, 2002

>> Okay, my fault. I thought the idea was that it all had to be at least closely reviewed with your partner, with code written away from the partner kept to a minimum.

Well, you've actually got the right idea, IMO.  The right idea being "take what makes sense to you and leave what doesn't".  Sort of what I was attempting, and still am, but made the mistake of calling it "XP".  Don't do that, because the book says XP is all or nothing. 

Call it HB - stands for "Half Baked".  That's my new metholdology.  Its never done, always half baked.  It recognizes that business is not a science and that there are no elegant laws as in physics whereby observation can be distilled into scientific fact.

Nat Ersoz
Friday, May 10, 2002

OK, John, those are interesting articles.  That is exactly what I was interested in.  Thanks for posting that and for the direct links.

However, I remain skeptical.  First, if I didn't think there were any clothes for "XP to be wearing", then I wouldn't have read XP explained twice - the second time taking notes.  So, I'm not hostile to XP (although, granted I made some hostile statements).

However, reading through the specific studies, much of the code and evaluation was done in a university setting.  The exceptions to these being Ken Beck's and cohorts already documented experiences.

For example, I am skeptical about the U. Utah experiment which found that PP resulted in only a 15% increase in man-hours worth of development and a corresponding 15% reduction in code defects.

The first thing that should be a tip-off is that the time scales are measured in elapsed time.  If this is indeed the case then it takes a team of 2 more time to complete a task than a loner.  In the best case, pairs completed the task at 80% of the loner.  That means a more than doubling of programming assets for the task.  Our company cannot afford that sort of productivity hit.

Secondly, the case for XP assumes that unit tests don't exist outside the non-methods universe (OK, I'm exagerating).  Neverheless, how does someone deliver code that has predefined performance criteria (as was the case in the Utah study) and not get a perfect score?  How does this happen?  You know the test scoring criteria, and yet you do not test to that criteria?  Again, I'm suspicious.

Finally, I agree that collaboration is a powerful tool (hence my ramblings in prior posts over the virues of cubes over offices).  It is not my attempt to discount collaboration.

Nat Ersoz
Monday, May 20, 2002

*  Recent Topics

*  Fog Creek Home