Is Xp Borg Development

This page is a perfect example of viewing XP as a solution for everything instead of the more moderate position that it works well for some projects while not well for others. Notice that neither I nor the other participants in the following discussion ever mention WhenXpIsaBadChoice. We only talk about XP in absolute terms. Personally, I hate this page for that reason - or at least my contribution to it. But it seems like it would be a mistake for me to edit myself. Check out the first couple of sentences, I totally miss the point that sometimes creating the plainest possible product in the shortest period of time is exactly the right solution for some kinds of development. It's not XP that I didn't like but instead, it is that I (personally) don't like doing those kinds of projects. -- RobertDiFalco

I'm being humorous and a little extreme with the page title, but my guess is that much of Xp would be very far from the way AlanKay, WilliamBurroughs, ErnestHemingway, or DaVinci would have liked to work. So much about ExtremeProgramming seems to devalue individual contribution and only really value the rapid creation of the plainest possible product in the shortest period of time. While there is much I like about Xp, other aspects of it seem to be a sad knuckling under to the pace of modern society, the rising homogeneity of the world, and the bottom line above all else. What I like about Xp are practices I liked before Xp called them Xp. Most of these practices are just good development idioms that have been around much longer than even Object Oriented Development. Practices like Refactoring (See FredBrooks), rigorous UnitTesting, ContinuousIntegration, UserStories, CrcCards, IterativeDevelopment, and so on. Maybe Xp gives some of these practices new names, but either way I very much like that Xp has decided to adopt these good practices into their methodology. I am a firm believer in the Igor Stravinsky's quote that "lesser artists borrow, great artists steal". :)

However, it is the side of Xp that seems to devalue the individual that concerns me. Silly things like individual modes of expression, unique talents, and individual areas of expertise seem to be thought of as disruptive or unneeded. God forbid you are an unusual person and have unique ways of working - those who do not fit into the Xp Collective are counterproductive underachievers. In many ways, Xp reminds me of the old 1950's style management practices where individuals were thought of replaceable parts. Kafka-esque managers attempted to build organizations where individuality was weeded out. This so sadly disregards so much of the progress that Tom DeMarco and Timothy Lister made over the years in an attempt to value the individual and reward unique skills. Resist the urge to think that I am somehow rejecting EgolessProgramming. This is untrue as what EgolessProgramming states is that we should all be open to criticism. Sometimes people use EgolessProgramming as a stick for PairProgramming, which is crazy since EgolessProgramming has absolutely nothing to do with IndividualCreation, just with the acceptance of criticism - which helps one to better themselves.

Here are some borg-like examples in Xp:

Let me close on some notes on DoTheSimplestThingThatCouldPossiblyWork. I've personally seen the religious adherence to DoTheSimplestThingThatCouldPossiblyWork result in some incredibly unspectacular systems that lacked an attention to detail - lots of rough edges - especially on web pages. I've rarely seen this create something truly great and polished. It almost seems like innovation isn't something that is valued by the strict adherence to this axiom. DoTheSimplestThingThatCouldPossiblyWork scoffs at the idea that ProgrammingIsArt. Did Mozart always do the simplest thing that could possible work? What about Frank Lloyd Wright? Really, if all you ever allow is PairProgramming, you have no choice but to always DoTheSimplestThingThatCouldPossiblyWork. Some how cogitating on an elegant solution has some how become unnecessary or "out of fashion".

As Albert Einstein once said, "One should make everything as simple as possible, but no simpler." -- RobertDiFalco

See: DesignByCommittee

Responses:

it seems that Xp is very far from the way AlanKay, WilliamBurroughs, or da Vinci would have liked to work
XP is about software development, not writing, painting or sculpture (This applies to the Mozart etc references as well). One of the axioms of Xp is that software construction is different from doing other things. You could ask AlanKay what he thinks of Xp, it might be more appropriate than guessing and making the attribution (apologies if you already have). TomDeMarco seems to like it, maybe it values slightly different set of individual qualities? -- TomAyerst
[RD: I think you are reading more in to my point than is there. I didn't say AlanKay would be anti-Xp, not at all, I'm not even anti-Xp. For all I know AlanKay loves Xp and further more agrees that there should be no SoftwareArchitect(s) and that all DesignBeforeCoding is a bad thing. I don't know. My guess is that certain kinds of projects can have their ConceptualIntegrity compromised by Xp while others may flourish with Xp. As for TomDeMarco, I do know that he has come out in favor of Xp, but I still see an "extreme" point of view in Xp that seems to have no tolerance for individual forms of expression. At the same time much DeMarcoAndLister say about TeamGel seems to be right in line with Xp. Now, I could be wrong but I do not think that AlanKay came up with the idea for DynaBook or SmallTalk in a team. But I do believe a team refined those ideas and turned them into something real or even that a team took ownership of those ideas and evolved them into something he may have never envisioned. That's a good thing. The best designs are those that have uses I never imagined. Really though, I don't know since I wasn't there. I think what is great about SoftwareDevelopment is that it allows many people to express themselves in many different ways but still come together to create something, possibly great. Personally, I have as much a place on my teams for odd-ball individualists as I do for catalysts (who may not program well at all) and those who only shine when working with another. My job is to get all these people to gel together - to actually create a clique where the members can feel an almost religious fervor for what they are doing. As for balance, just look at the top of this page where someone decided to respond to my questions with a mocking AreSpecialistsIndividualisticEgomaniacs. Is this balance or tolerance for diversity?]

My line (Attempt at humour, failed). I think XP values people and teams, it also places a great deal of emphasis on communication and passing on information. It may not tolerate well people who insist on working alone but that is a choice thing for them. I would not like to work on a clean room project, but other people do; I would find the shuttle code shop a real trial but the team there seem to really enjoy it.

If I were recruiting an XP team and a great and famous developer turned up who I knew could turn out reams of effective, elegant code but who insisted on telecommuting and refused to show his code to anyone else or write any tests, I probably wouldn't offer him a job. I might miss the software equivalent of Mozart that way, my risk. On the other hand, a genius who is willing to 'go with the flow' might find an Xp team a very friendly and effective environment (see XpIsGeniusFriendly). On the third hand, I would try and go the extra mile to fit someone who wanted to join in but had some barrier (disability?).

XP orders its skill set differently. Obviously technical ability is important but communication skills and willingness to really work in a team are as important, that means the willingness to compromise sometimes on the part of the members.

I'm not sure I put all that very well, hopefully others will. -- TomAyerst

I think you put it very well. -- RobertDiFalco

You might want to compare XP with AlistairCockburn's Crystal methods or Scrum or other lightweight methods that are less extreme than XP. Alistair says that XP trades discipline for process weight (that's why Pairing is so important, it bolsters discipline up front rather than after the fact) but within (because of?) that discipline there is a lot of room for expressiveness and creativity, perhaps Jazz would be a better metaphor than the Borg? -- TomAyerst

Doing the simplest thing that could possibly work implies rough edges
A fair observation; just piling up straightforward solutions will eventually lead to a humongous hairball, but DTSTTCPW isn't meant to stand alone: one must also RefactorMercilessly, to remove exactly those rough edges.
[RD: I have no problem with RefactorMercilessly. I have practiced this for at least 12 years. It's always just been natural for me to continuously widdle away at my work. However, I have sometimes seen my refactoring add the very same code I had removed while trying not to perform PrematureGeneralization and in an effort to adhere to YouArentGonnaNeedIt.]
There's something odd here: your refactoring added what you previously removed in order to avoid premature generalization? If YAGNI, then why did you put it in in the first place? Certainly, going round in circles like this will be frustrating. So don't do that.

The way I read it, this paragraph meant: "Sometimes the code I removed because it was PrematureGeneralization has turned out to be needed after all, so I had to add it back." I don't think that's odd - it's not generalization per se that's bad; the badness is in the premature-ness. No? RD, please fix this if I've misread your statement.

[RD: Yeah, that's what I mean. FWIW, only experience can tell you what generalization is premature. What is premature? I've seen the militant avoidance PrematureGeneralization result in some mighty specialized code. Honestly, In practice, I see programmers having a harder time generalizing enough more than I see them generalizing too much. I've also (and this is all before Xp - I doubt the practitioners where even aware of Xp) seen programmers (usually programmers from modular or procedural backgrounds) wave the stick of PrematureGeneralization and YAGNI to justify the lack of abstraction in their designs. Then again, YMMV.]

anyone can work on any part of the system
- I think it's a given that this involves pair programming. In other words, it's not that you understand the whole system, it's that for any part of the system you plus 1 other guy can understand it. The specialist is the guy you pair with.
[RD: This is fine sometimes, but why be so extreme. Why not let the specialist cut loose on some part of the system for a couple of hours without having to drag me a long when I could be working on some other part of the system. Moderation is usually more optimal than extremism. I'd say PairProgramming is good in moderation. It's very bad to never perform PairProgramming just as it is to only perform PairProgramming. ]

The problem with the specialist doing a couple of hours here, a couple of hours there is that after 6 months there are no-go areas in the system for the rest of the team. Then the specialist takes a holiday and development stops for an iteration, or slows down as the team tries to work out how it works. Then it sees that because he was working on his own the specialist has been a bit lazy on the unit tests and the once and only once rule so when they make the fix the system goes pear shaped. -- TomAyerst

[RD: This is a great point and something one must always keep in mind with a team. However, at the same time it's like an orchestra when you can get all those pieces gelling together. Wow.]

the rapid creation of the plainest possible product in the shortest period of time
I don't see this. What I see is a product that is custom fitted to the needs of its users. I also recognize simplicity of form as a beautiful thing. I strive to incorporate such beauty into my work and it seems to be appreciated by the people I work with. There is a certain elegance to code that is incredibly simple yet does something complex.
[RD: This was my response to seeing so many argument for Xp referring to how it is faster, as if speed was the most important thing. Personally I like the concept of SlowDownToSpeedUp. Anyone who chose SmallTalk over CeePlusPlus knows that speed is a two-edged sword. PairProgramming is faster, DesignUpFront is slow, YouArentGonnaNeedIt, DoTheSimplestThingThatCouldPossiblyWork -- all of these seem to imply that speed is more important than perfection.]
Xp reminds me of the old 1950's style management practices where individuals were thought of replaceable parts
No. XP brings about just the opposite. Each individual is valued as part of the overall project and not considered replaceable just because some part of the system is now finished. XP recognizes the human issues and deals with them directly. You pair and attend StandUpMeetings so that you will feel supported and encouraged by your team members not because you will be replaced.
[RD: Once again, this is great. But why only this. Why never assert yourself as an individual? Why not have the best of both world, strong team gel and plenty of opportunity to assert a personal vision in some areas of the system?]
individual areas of expertise seem to be thought of as disruptive or unneeded. God forbid you are an unusual person and have unique ways of working - those who do not fit into the Xp Collective are counterproductive underachievers
XP is much more forgiving in this respect than any other environment I have worked in. Everyone is given the opportunity to work at their own personal best, no more and no less. You don't have to be a genius to be productive on an XP team, but it won't hurt you if you are. If you look around a bit you will see many forms of expression at an XP project, even more so than any other type of project.
Everyone on the team has strengths and weaknesses. XP acknowledges that and provides support for it. Everyone on the team knows everyone else well and recognizes who is best at what. We don't like to PigeonHole people as worthless for anything else, instead we foster an environment where everyone shares their knowledge and learns new things.
We allow people to take on something brand new and provide support that ensures they will learn and succeed. It is very difficult not to fit into an XP team because there are a very few things you are required to do. Some of them do mean you may have to work in a new way, hopefully being able to use emacs is not the only talent you have. But if it is, that is OK too because you will learn many new things in a very short period of time with teachers who are happy to help you.
[RD: This is great. Working in new ways is a good thing.]
Sometimes people use EgolessProgramming? as a stick for PairProgramming
There is plenty of ego. It is just redirected to include every line of code in the entire system, not just my stuff. Since you and I both own the entire system we work as a team and are able to criticize each other and accept criticism in the same spirit it was given. But make no mistake; our system is the best damn system in the world.
[RD: Criticism is good so is CollectiveCodeOwnership. But it is also good to have a feeling of individual ownership. In fact, I spend a lot of time as an architect trying to get out of my teams way so that members can feel that certain parts of the system are theirs. If I go to fast, this will never happen. I'll be gated by them and they'll not achieve things they could have because I always rushed in with the answers. There is plenty of room on a development life-cycle to have both PairProgramming experiences and non-PairProgramming experiences. Once again, it is the extreme I object to.]
No chance of creating an environment for yourself, expressing yourself in your own space
You are welcome to create a personalized environment for yourself. You just can't spend your whole life bottled up in it. Instead, join us in the clubhouse and help us customize our space together.
[RD: Lots of people like to create a personalized environment just to show it off to other people...to express themselves. Not to become bottled up in it. This is the incorrect assumption made by many virtual offices with proximity sensors - any phone could be your phone, any computer your computer. It underestimates the bonding power of individual expression.]
I really value those people who are amazing in some specific area of technology. Maybe someone can debug better than anyone else, another individual is really good at distribution while yet another is singular in their database skills. This is a good thing, not a bad thing
Exactly so. Wouldn't you want the person who debugs the best sitting next to you when you can't seem to get a bug under control? I know I would. In fact I would like very much to learn from this person how to debug better.
[RD: Absolutely. But not all the time. As you say, I would like it when I can't seem to get a bug under control. And I would certainly want to learn from them. There is a middle ground, it isn't either you Pair Program or you don't learn from people - you can do both.]
Xp seems to require that each participant understand the entire system
No. XP requires everyone know the system well enough to avoid breaking it. That is not the same level of detail.
[RD: I'm glad I was mistaken on this point. It would have been ashame to throw out encapsulation.]
The bar is lowered since the system must be small enough to be understandable by all participants
No. The bar is raised; you must make the system easy to understand no matter how big it gets.
[RD: I response to this response with your next response.;-) Some things aren't easy. Maybe it's that Xp is meant for only a certain kind of development. This would make sense since everything is not a nail.]
As Albert Einstein once said, "One should make everything as simple as possible, but no simpler."
We agree. -- DonWells
my guess is that much of Xp would be very far from the way AlanKay, WilliamBurroughs, Hemmingway, or da Vinci would have liked to work.
Maybe so. But since Leonardos are thin on the ground, would that matter so much anyway? It's questionable if a team could survive for long with a Leonardo, a Hemmingway and a Burroughs on it (Papa and Bill might well end up shooting each other, and a few by-standers, for one thing), but large numbers of individual geniuses are not available anyway. When they are we may have to reconsider, but for now all we average types can probably muddle along with XP well enough.

Actually, I am a RocketScientist, and I find that XP makes me better. I'm not limited by it, because it's not limiting, and because I choose, in any case, not to be limited. Borg technology doesn't exist. The only way we can become drones is to choose to become drones. -- RonJeffries

It's questionable if a team could survive for long with a Leonardo, a Hemmingway and a Burroughs on it...

I agree with and I'm not so sure I'd agree with or. (Btw, I specifically chose these names not so much for their genius [or at least not in the RocketScientist sense], but more for their individual vision and peculiarities). I wouldn't want an entire team of them but I do strive to create an environment that would allow one or two if they came along - even if it meant letting go of my inability to understand the way they worked or if it didn't fit into my rules of how an engineer should work. Of course, if they hurt the team they would be gone as no individual is more important than the team as a whole. However, I usually find that teamacide or destructive behavior has more to do with an attitude than a way of work. There have been a number of times I have been paid off for adjusting my preconceptions or rigidity in order to be more inclusive. I tend to suspect any process that dictates a single right way to work or collaborate but many wrong ways. For example, I see PairProgramming as a tool (and a great one at that!!), I don't see it as an absolute. While I am a great believer in lightweight processes, I don't think (as many do) that rigidity needs to compensate for weight. -- RobertDiFalco

I think the discipline-weight trade-off is 'not proven' as yet. If you can tinker with it then that's fine. The testimony of the people who have been doing this for a while seems to suggest that there are trade-offs, at least with XP. Part of the issue is that XP is a system and each XP practice acts on the system in a number of ways. PairProgramming for example acts on:

As soon as you aren't pair programming all of those effects tend to zero with the ensuing impact on the system. It is therefore a judgment call. If you think the benefits of not Pairing for a while outweigh the benefits of always Pairing then go for it, as with all things YMMV. In a complex system like a project it's actually quite difficult gauge the impact, that's why real project management is hard. It's also why XP proponents argue for trying it out As Is before tuning. -- TomAyerst

Tom, I could be misunderstanding you but it seems you are saying that when not PairProgramming all of the above bullets are unattainable? I don't think this is the case - there are many idioms developed and proven over decades to ensure these. Moreover, each can have LightWeight and OverWeight versions. :-) PairProgramming is just one specific method that (rather neatly) slices off a few extra steps such as peer reviews and walk-throughs. On our team (we are small), the entire team likes to get together for "reviews" - they are normally ad-hoc and occur every day. This allows what you call System Knowledge Distribution to go beyond the pair to the entire team. We huddle around a 'puter (if its code) or a white-board (if design) and bonk heads. In fact, there is so much "collaboration" that after team-gel sets in, we tend to get Klingon looking foreheads (i.e. head-bonking calluses). On my current team (just moved into construction) we will be practicing many different idioms including PairProgramming, CodeReviews, DesignReviews, Walk-throughs, Design upfront, Design in Code, Test before Code, and so on. We do scheduling very much like XP - something like a cross between EvolutionaryPrototyping, traditional TimeBoxing and some XP (but with less discipline about Customers writing all the requirements). We wont even need any reviews or PairProgramming for someone to let me know I have neglected to write unit tests before checking in some code - if programmers don't let me know, our configuration manager will (and not too pleasantly!!) -- RobertDiFalco

It looks like you have everything well in hand. As others have said, if you have a system that works don't change it.

The point I was trying to make is that a project is a system, not just a bunch of things you do. Changing one element will have multiple effects on multiple levels. Most projects actually have outputs very different from those expected or desired by their managers and members. The XP method seems to be a way of putting the system together and getting the expected outputs (at least that is peoples experience). It may be that they have been lucky, had extra-ordinary people or it really might work. People who have run projects this way for a while have experienced high levels of productivity, quality, developer and customer satisfaction. They have done this on more than one project (which moves it from just a successful project to a method :-). The system level effects are probably the reason why XP works better than applying a couple of the practices.

Back to PairProgramming. Of course you can get the results via different means, but those means will have different impacts on the system. If you go in for code reviews then they may have to be scheduled, this takes time so the code has to wait for a day while the review is organized. During this time the code is in limbo, on the other hand when the review happens more people will see it. Different effects. Compensating for them means perturbing the system in a different direction. It sounds like you have sorted you team out so I really wouldn't fiddle with it. Remember, lots of little steps with a lot of feedback applies to changing the process as well as the product! -- TomAyerst

Excellent point. BTW, I don't honestly think I have anything well in hand, (otherwise I wouldn't be picking apart XP for ideas) but I do like the direction I've been heading in over the last couple of years and I'd like to see where it leads me. However, I'm certain it would be too informal for most. Right now, I don't do a lot of the metrics XP recommends and I probably should. What we do certainly wouldn't scale well to a Large Project with a team of 20+, however, it's great for a Large project carried out by a Small team (of maybe 3 to 5). FWIW, I hope it is clear that I wouldn't even waste time criticizing XP if there weren't a ton of things I liked about it and hoped to integrate into our approach here. I'm open to anything so maybe as I continue to move in this direction I will find that I disagree with my current position and end up preferring a more disciplined adherence to methodologies. I do find all the XP practitioners and prognosticators to be high-quality and pragmatic thinkers all of whom I'm sure I would have a great time working with. -- RobertDiFalco

BTW, here's a new one. There's some question in a large marketing-driven commercial software company whether XP would fragment project management, development, QA, customer support, and marketing departments from one another by taking such a programmer-centric approach. I could be wrong, but it seems to me that there is no reason Marketing, Customer Support, and actual end-users couldn't fill the Customer role. In this way it would bring the company together even further by requiring some members of Product Marketing or Customer Support to sit together with Development. I know XP'ers are very strict about their terminology but do you think this is a fair extension of the traditional Customer role? -- RobertDiFalco

I'm sure XP doesn't need to harm market driven development. The secret is (I hope) to make sure you always know who your customer is. There are two aspects, planning and on-site customer.

If the developers never meet 'real' customers then their customer should be the marketing department or the 'product' manager if you have such a thing. If you have multiple customers then someone needs to elect a CIC (Customer in Chief) who can prioritize the stories.

The on-site customer is more tricky, this may well be a place for a Business Analyst type role where someone learns how it should work and then is on hand for the developers to ask. The risk is that they don't actually understand the customer requirement and you develop the wrong product. The alternative, going back to 'real' customers, gets a more accurate requirement but slows down development. YPYMATYC. -- TomAyerst

See also DistributedMind where this topic has already been hashed once.

CategoryExtremeProgrammingDiscussion