Slashdot Mirror
Questioning Extreme Programming
In short:
This is bound to a controversial and widely read title -- it is a critical but fair re-examination of all of XP's assumptions and core practices. It provides a much needed comparison of XP with other, less popular, methodologies. Overall, XP emerges favourably, with one serious caveat -- the author concludes that XP is only suitable for a very narrow range of projects, and those that can fulfill all requirements probably stand a significant chance of succeeding using any of the similar methodologies. As with programming languages, there is no silver bullet -- put XP in your methodology toolbox, know when it is appropriate and only use it then.
A couple of interesting specifics:
- The author specifically argues, and I agree, that what the XP literature badly needs is a DSDM 'suitability filter' to advise project leaders as to whether XP is for them.
- In the preface, Kent Beck describes the On-Site Customer role as a team, and not an individual role.
This is the 8th title in The Extreme Programming (XP) Series from Addison-Wesley, surely the most widely read series on a software methodology ever! (If that isn't achievement enough, XP also made testing sexy again. I hear that accountancy firms are looking for Kent Beck to do Public Relations work ...) For those of you who have been living under a rock for the past couple of years the previous titles are:
- Extreme Programming Explained (Beck)
- Planning Extreme Programming (Beck & Fowler)
- Extreme Programming Installed (Jeffries et al)
- Extreme Programming Examined (Succi & Marchesi)
- Extreme Programming in Practice (Newkirk & Martin)
- Extreme Programming Explored (Wake)
- Extreme Programming Applied (Auer & Miller)
This new addition to the XP library feature a foreword by Kent Beck. This is important as many of the reactionary XP fan-club will not like this book -- it challenges XP, and I am delighted to see this title as part of the series. Beck admits he doesn't agree with McBreen's conclusions, but asks you to read the book and decide for yourself, conceding that the arguments are fair and reasoned. I come from a scientific background and distrust anything except wide open debate, a position many who welcome XP will surely agree with. A book challenging XP can only help persuade people to give it a go, by addressing their fears and explaining how to manage any real risk.
Check your sourcesPete McBreen is the author of the excellent Software Craftmanship: The new imperative, a 2002 title from Addison-Wesley. In it he outlines an alternative to the software factory model behind much of traditional software engineering thinking. He proposes a collaborative model with small teams, where the software coder is seen as a craftsman in constant dialogue with the customer. Sound familiar? It should, this is a cross between a methodology and book of advice for career programmers, and fits squarely within the values proposed by the Agile Alliance, and arguably popularised most by XP.
I highly recommend Software Craftmanship, and can think of few authors who are as well positioned to give an analysis of XP as it currently stands.
What is the book about?Questioning Extreme Programming does just that -- it's the first title in the series to take a skeptical look at the rise of this popular methodology and question some of the key assumptions. Arguably there was material like this buried in Extreme Programming Examined, but it suffered from a fragmented, detailed view, due to it being a bound set of conference papers.
The author tackles XP in a fair way -- he's extremely excited by the methodology, and it's clearly in accord with his own preferred approach. What he does is tackle each of the XP tenets in turn, questioning their validity, and then moves on the compare XP to other Agile methodologies and asks how XP stacks up against the competition. He also has a look at the common mis-conceptions (from both sides) about XP, and tackles the key arguments against its adoption in the same way.
Let's have a look at the contents to give you an idea of the structure:
- Introduction.
XP: Hype or HyperProductive? - What is a methodology?
- What do methodologies optimise?
- What are XP projects scared of?
- What do other methodologies consider important?
- What is important for your projects?
- Questioning the Core XP Practices
- Planning incremental development
- Truly incremental development
- Are we done yet?
- Working at this intensity is hard
- Is that all there is to XP?
- Questioning XP concepts
- The source code is the design
- Test first development
- Large-scale XP
- Is the cost of change really low?
- Setting the dials on ten
- Requirements: Documentation or a conversation?
- Is oral documentation enough?
- Playing to win?
- Understanding the XP community
- ReallyStrangeSayings
- Feel the hostility; experience the joy
- Transitioning away from XP
- Your choice
- Is XP for you?
- Do you have a suitable first project?
The whole thing. Let's start with the basics, the high standards of the XP series are maintained, with flawless editing and layout. Moving on, the author's position is admirably neutral -- he is knowledgeable about the field, and although he wants to be converted, he argues only from first principles, and only from the evidence. Similarly, at no point did I think he set up a straw man, or tackled the opposing issues in a different manner. I particularly admired the way he avoided polarising issues -- "All models are lies." -- dismissing them as unhelpful in his current investigation. (He points out that much of the fire in the XP debate has resulted from the use of deliberately polarised opinions as a unambiguous goad to further debate within the XP community. Fine within the gang, inflammatory outside.)
The structuring of the book is of particular interest -- the argument could easily sprawl, but is restrained into very short sub-sections, with each section sporting a clear list of summary bullets. As much as is practical, each challenge to a tenet or practice of XP is discussed independently. (This comes across as simple and straight-forward and you may wonder why I even mention it, but I think it's a fine piece of editing and worthy of praise.)
The sections of the book that I enjoyed most were those dealing with the SmallTalk culture that XP grew out of -- he presents an interesting analysis of why XP works within that environment but discusses how that environment is NOT typical of most development. I have some bias here due to my own experience, see below, but had to agree strongly with his contention that XP is weakest when it comes to team resourcing, and the on-site customer. In particular, he argues that while XP restores dignity and human rights to the programming team, it does so at the expense of the poor frazzled customer. Similarly, he argues that the pre-conditions for XP, in terms of the programming staff, are so high that almost any methodology could be made to succeed with that team.
Don't get the impression that this is a negative work -- it's not. Most of XP emerges intact, and I felt that the author genuinely wanted only to restrain people from adopting XP in inappropriate situations -- not to persuade people to avoid XP. In doing so, he actually protects XP from bad press due to teams failing when trying to adopt XP, them blaming XP itself, rather than their own inappropriate circumstances.
What's bad?Er, not much. He sort of pulls in some material re Open Source early on, but fails to particularly build on that comparison, moving instead to a comparison of Agile methods in closed source circumstances. This is a feeble objection -- but really, it's all I've got this time!
Anything to declare?I should probably give a quick sketch of my background before I finish as I am slightly biased -- most of my work has been in the telecommunications sector, where I either worked with a large code-base (legacy) or a large, distributed team (new development). In no way was I working in the XP style, although I became test-infected easily I found it difficult to even imagine how to apply some of the XP practices to my workplace.
XP changed the way I code and work, for the better, but in a large environment, with no contracting customer, and few experts on a complex domain involving simultaneous hardware development I couldn't see any way to do XP. I'm not saying what we did was good, I'll be the first to admit it was broken (hmm, and I'm unemployed now, time to go and think about cause and effect!). The key assumptions of pure XP just didn't fit the industry I've seen most of. (To be fair, McBreen would have called these projects "systems engineering" and placed them outside of the discussion.) Now that I'm seeking employment again, I'm a lot more aware of methodologies and am much keener to work within an Agile framework, as I believe that all of the methodologies, XP included, offer a much better way of developing software. However, the key point remains -- XP cannot be applied everywhere.
Lastly, I should make it clear that I received a review copy of this title from the publisher and did not pay for it. I paid for my own copy of Software Craftsmanship.
You can purchase Questioning Extreme Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Just like Clinton.
I personally prefer to be on my own. I could see how managers prefer it because it forces more work to be done and yeah, it prevents a lot of errors, from my experience.
But I hate it - I hate working right with someone else.
I personally would rather to just be near someone and ask them questions about code if need be, but I hate the XP experience personally.
There are some odd things afoot now, in the Villa Straylight.
It is a good idea (for somebody) to experiment with software engineering ideas. I have no problem with that. However, these conditions should be met:
1. Test it on willing and knowing *volunteers* only.
2. Don't claim it is "better" until it has been road-tested for a while. At least 3 years and preferrably 15.
3. Identify where it works and where it does not, or at least be clear about the domains and situations and scope about where it does work so far.
There are too many credit-cravers and talking heads out there pushing buzzwords into the mainstream before they are tested properly. They should take some clues from the medicine industry. Sloppy pushing may not (directly) kill people, but it can certainly kill the economy and IT credibility, as we have already seen.
Table-ized A.I.
Didn't this get addressed in the old file "The Tao of Programming"?
(to paraphrase, since I don't have the original text handy):
A manager approached a programmer and asked how long it would take to build an important project. The programmer said, "Six months."
The manager said, "that's too long. What if I assigned two programmers to it?"
"Then the project will take a year."
"That's terrible. I'll give you four programmers!"
"Two years."
"Aigh! I'll give you a hundred!"
"Then the program will never be completed."
Dig?
Farewell! It's been a fine buncha years!
(I can see why you posted AC, because you would likely have been modded down.) Anyway, your observation matches my experience: at our shop we tried pair programming and it not only resulted in a fair slowdown, there were also other effects that we noticed:
- the pairs spent a lot of time talking to each other about off-topic things.
- it lead to the formation of "expertise" domains, where one developer would do a specific task because he was treated as the expert, when the other just sat nearby and stared.
- the number of bugs was not significantly reduced
- bad design was not eliminated
So what we do know is, we build small groups of programmers and give them a modular task. They can do as many meetings and talking and planning as they like, but then they distribute the work amongst themselves and get it done alone. The code is then later reviewed by a "review partner" from the same group. It works nicely!
They'd point towards "the planning game," the XP deliverable for project management. (See Planning Extreme Programming for details.)
They'd point towards "user stories" (very similar to use cases), one XP deliverable for requirements gathering.
They'd also point to projects where the requirements weren't well defined up front and changed very quickly, and the cost of maintaining detailed requirements deliverables would have slowed the project down enormously.
And what project doesn't fall in that category? It's a fantasy to think, ala classic "waterfall" development, that the requirements can be set in stone before any of the design, coding, and testing is done. Requirements grow and change as the project progresses, in ways peculiar to the "softness" of software development. (No one would start a project to build a footbridge over a creek, then halfway through want a rail bridge over the Mississippi River.)
XP may not be the best way to address this, but it's one way; and even as McBreen concludes, it's a good way for some projects. For all projects? No one's saying it is.
Stupid job ads, weird spam, occasional insight at
I'm a loner. I don't want my idiotic teammates getting into my code and fucking it up. If that makes me unsuitable for employement in an XP shop, screw it, I'd rather be building things anyway.
Perhaps this will help: The Rules and Practices of Extreme Programming
Except for the Pair Programming I don't see these as anything other than a verbose idealistic approach to the customer --> product cycle everyone knows well.
0xfeedface
Is this Google elite enough for you?
And how long exactly did you work in pairs?
I mean, you are very convinced that it does not work: the slower on drags the pair down
I get it now, you tested it and While they are wasting time coordinating with each other is just becaue one was using the keyboard and one the mouse?
Did you ever wonder why every commercial aircraft of a certain size has a captain AND a co pilot?
Because the co pilot might realize an error or a danger the pilot did not realize.
Same for programming in pairs. One person is more the organizator, planner, black board, defect and error finder while the other one codes.
How many compiler errors do you usaly correct after a compiler run? How long does it take to get 10 lines changed/eddited/added and compiled successfull?
How long does it take to get 10 lines into production?
And furthermore: what is more productive?
A pair creating 100 lines of code distributed via 3 classes in one day and getting it into production another day or having to single programmers coding 200 lines of code where 50 lines from each one are similar to the other ones code resembling the same concepts expressed by different people?
Now you have 200 lines to test, to maintane to debug, to refactor to zip compress and install.
Please stop bashing something you have not at least used/applied for a couple of years, and don't call yourself an expert if you have not used it at least for 10 years.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
In my company all tasks are defined to be 30 minutes long.
A person gets 6 to 8 tasks assigned per day.
One who can not cope with 6 to 8 taks in 8 hours is overworked, overstressed in relation to his abilities.
The guys who COULD do 10 to 16 of the taks because they are faster are oblieged to help/educate the guys who fail.
Pretty easy. Someone who is not able to share his knowledge by "helping" is asked to write a how-to and to give a 30 minutes talk about it.
The missing hours in the 6 to 8 tasks above are spend in meetings, email or at customer side, or: in making how-to's and giving talks.
If one thinks he is giving to much og his knowledge away, he is at the wrong place.
If one can not explain what that is he had just done/made he should make it in a way wich does not need explanaition.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I can see where your comming from and I totaly aggree
What happens when the single progammer is sick or leaves, yeh I can see how productivity is going to sky rocket.
How about the cross training that goes on when you have more than one person working on a project, that's useless of course.
Social aspects to working with someone else are a right pain, I wan't to work for a company that sticks me in a hole and leaves me there, that'll get the most out of me, and I'm sure to stay.
"Windows vs. Linux", Ok I'm no windows fan but has anyone noticed all the bickering that goes on in the Linux comunity,
I can see the productivity gains apearing right before my eyes (are there still atleast two VM's kicking around?)
thank God the internet isn't a human right.
The time that is used up when the better programmer is slowed down does not get repaid through gains in productivity of the pair. The slower programmer will simply drag the programming pair down.
I've been involved with pair programming for about 2 years now, and while we don't do full XP style development, it has been extremely beneficial. We are both expert programmers, but I do all of the typing. The benefits are the ability to have conversations about issues the moment they are encountered. Rather than coding a workaround or the first thing that comes to my mind, we discuss it and the results are spectacularly better. We decide upon a solution and code that, generally much better than what someone would come up with alone. Ideas are questioned and assumptions are challenged.
He is also able to be giving me a constant just-in-time code review. We catch dumb mistakes that the compiler wouldn't, simply by having more eyes looking at the code. When writing test cases, we both come up with test scenarios that the other hadn't considered... as a result, the test suite is far superior to what it would have been.
Additionally, working in pairs means that more than one person knows the code. This is good for lowering the "bus count". (That is, how many people can get run over a bus before your project is seriously in jeopardy.) With more people understanding the code, I can go on vacation without worry of a critical bug being discovered, and trying to tell them how to fix it from a phone halfway across the state.
Yes, it does slow us down a bit, but I wouldn't consider it a waste whatsoever. It's an incredibly bug-free, totally reliable system. That means little to no time wasted trying to figure out crashes. The time is more than made up for when you consider debugging time.
My experience with non-paired programming does not have as good of results. Even if you threw out everything else about XP, the testing and pair-programming have been the two most valueable ideas it offers.
Everyone is posting about XP but I would like to address the review.
It was rather thin. I didn't see much insight into the book's ideas or even the writing style. I didn't come away with any sort of idea if I should buy this book or if it would be of use to me.
I like book reviews. I think this was more like a very short book description and summary of the table of contents. Reviews talk about a view and not just a summary.
The best technique I find is to use a concurrent versioning system (I HATE the bondage-and-discipline exclusive checkout stuff) and _allow_ programmers to work in pairs if they so wish (this works best for people of approximately equal abilities - if one guy can't stop typing and hand the keyboard to the other guy without any fuss, then they're not suitable for pairing), and with the understanding that they will be told off for too much off-topic discussion, but _require_ that code merges be done in pairs.
That means that single-programmer originality isn't necessarily cramped, but paired-programmer attention to detail and common-sense-checking is applied when merging changes.
The problem with all software methodologies is that they are usually associated with some software guru who is trying to make big bucks as a consultant selling his brand. Also methodologies very often become religions, with the head guru being the leader of the cult. This is understandeable since most software developers depend on a song and a prayer to get their code to work. XP is a good example of both trends.
I wrote a white paper on software methodology which you can download here. I am an agnostic when it comes to methodologies, but there is alot you can learn from what's out there.
In the case of structured programming, I wouldn't say that it's come and gone; rather that it has simply been pretty generally adopted, and hence isn't trumpeted or bragged about.
Some IT fads eventually work and some don't. In my observation the success ratio is roughly about 1-in-5. Structured programming (no Goto's) and relational databases seem to have pretty well "stuck". OOP and Client/server are kind of in the same middle-land boat. They seem to work okay in some niches but not others. I remember the tail-end of the CASE craze. Then there was the Expert System craze. In the late 1970's was the "extreme" top-down craze, which was actually the extremist end of "structured". It later mellowed out to being at a routine or module level instead of application-wide. Thus, even good things can be taken too far.
Now we have web-applications, web services, UML, and XML-everywhere fads that are having their try. (Curiously, I just saw part of an article that claimed very UML-like approaches were tried, and failed, in the 1970's IIRC.) Most of these I would not personally bet on lasting in their current form, beyond minor roles. I think B-to-B web applications will be replaced by "remote HTTP-friendly GUI" technology of some sort (like XWT or SCGUI).
Table-ized A.I.
The one thing I could never see anyone in upper management buying into (aside from the name Extreme Programming) is the concept of Peer Programming. Allocating two perfectly capable resources to one desk during all development time simply does not seem feasible (not to mention desireable) to me. How many of you true developers out there would like one of your co-workers over your shoulder the entire time you were writing code? Or better yet, how would you like to be relegated to being in the passenger seat and simply observing and offering verbal input to the development process? Not very many of you I'd imagine.
Extreme Programming does have quite a few refreshingly positive aspects to it however:
Come out with small releases and come out with them often. This keeps the customer very involved in the entire development process and goes a long to to ensuring they (a) get what they want out of the system and (b) take on a true partnership role in the project. This is especially helpful, since we all know that specs often will begin to change the minute they're committed to paper anyway.
Full testing of the entire system each time a release comes out. How many times has a small change in one area of the system ended up affecting another in some unexpected way? This concept takes care of that situation as well as gauranteeing comprehensive Q/A in general.
No fear of code refactoring. I love this one, because we all know what a pain in the ass it is to have to completely reengineer some piece of code or process that is in place and working, but is discovered to be unscalable or deficient in some way in regards to future use. Building around it only makes the situation worse though, doesn't it? Don't be afraid, rewrite it and make it right. There's usually no way of knowing everything a specific process may be called on to do from day one anyway.
We all own this code. The concept of all developers being able to work on any piece of the system makes much sense. I used to work in one shop where the brilliant mananger decided everyone would have one area of responsibilty, thus having him make statements to users like "Oh sorry the search engine is not working, but we can't get it fixed till tomorrow since Andy is out today and he is the Search Engine Guy". Everyone being able to change the communal code does require that you have a group of developers who are all competent of course - which is not always the case in the real world.
I guess my take on it is that you simply cannot apply the principals of Extreme Programming as a simple "black-and-white" practice. It's really got to be somewhere in the middle to make it work in the real world ...
Context? Articles written by convention attendees? ;)
Ok, ok, seriously. I don't know; the point of the original joke was that one programmer working alone can control his design and work quickly, and that too many cooks spoil the broth, right?
Well... If I have to work closely with someone in a partnership, then I'll have to compromise with him on every issue in which we differ. Reaching those compromises will take time and result in a mediocre product. Arguing over design philosophy will take additional time. Shouting matches over which widget we're going to use this week will take up more time and annoy others. It would be much easier and cleaner if we were each given our own independent modules to write, with a contract laying out the interface we have to follow, wouldn't it? Instead of teams -- distributed, independent development.
Sort of like the programmer telling the manager, six months if he works solo, a year if he has a partner, and so on.
But, you're right; I dropped it in out of context. Still -- you have to admit, it's a killer description of a fundamental truth.
Farewell! It's been a fine buncha years!
I joined a company a year and a half ago, becoming part of an Extreme Programming development team. And I was pretty skeptical at first.
/share/ computers? That we have /weekly/ design meetings? And all sorts of other strange and unfamiliar things.
/before/ the code was written, and the code couldn't be checked in until the tests -- and all existing tests -- passed.
/had/ to be held standing up. (I.e., everyone starts to get tired, and when people start sitting down a meeting had to end.) We took a fifteen minute break every two hours to keep from getting into fugue states, and because of that productivity we were never working overtime (thus keeping us from burning out). It was one of the most rewarding development experiences I've ever had.
/fail/. We lost support within the rest of the company for the XP process, and that hurt a lot; XP relies on getting weekly or bi-weekly feedback from your 'customers' (i.e. the target for your project), as well as having them set what the more important tasks for the next two weeks were. Suddenly, we were having to plan out things six months in advance and operate in a vaccuum, which really hampered the Extreme Programming method. In addition, our team was expanded...and we learned the difficult way that while XP works really well for an 8-person team or so, it does /not/ mesh well with larger teams.
I mean, here I am, coming into a compiler-and-assembler design team and I'm being told that we have to
But to my surprise, it worked. We each had our own 'personal space' computer for e-mail and everything else, and when we were working we went into our lab as a group. We'd look at the board of current 'stories' (overall larger tasks) and pick a 'task card' from the story. (Literally, taking an index card off the corkboard and clipping it into a little holder by our computer.) And then you sat down at a computer with two monitors, two keyboards and two mice and you pair programmed. If there were an odd number of people, you had to have someone else go over your code with you before you checked it in. All code had to have tests written for it
And to my surprise, it worked. With two people looking at code, the little mistakes were harder to make. Design problems were more easily tackled. Because we all shifted around and changed partners a lot, we all learned all the areas of the code and had a better understanding of the system as a whole. The way tasks and suchnot were partitioned out worked very well. Meetings didn't interrupt the flow of things, because almost all meetings
BUT...this also became a story in how Extreme Programming can
So, I actually would probably agree with the book's assessment; XP is well-suited for certain situations (small team, active customer feedback and support, quick dev cycles), but will fail miserably (and I do mean miserably, as in ruining the morale of the team) if you do not have the full support infrastructure.
Admittedly, some of XP's practices -- tests written before code, meetings held standing up to keep them from dragging on indefinitely -- work pretty well even outside XP. But the system as a whole works well only within a specific target range.
--Rachel
Wether or not XP is going to stick is a very interesting issue. However, There is a very important point that goes unnoticed: WHY all this talk about XP?
In the past few years, most software processes were generally loathed by the average geek, because there was "so much documents to generate, and so little code to write". The real extreme (no pun intended) geek would even consider business process analysts a "project overhead". All he really wanted to do was coding.
Then came those agile methodologies like XP, and all of a sudden there are loads of people preaching that this is it, that XP will save us. that using SCRUM improves your lifestyle. etc.
My point is: a lot of people tend to like XP NOT because they acknowledge it is efficient as a software process, NOT because they used it and their project was a ressounding success.
My point is: a lot of people tend to like XP because they, in a way, are seduced by its promise of working by a methodology where the focus is coding. seduced by the promise that they dont have to write "useless" documents and activities, and their project will thrive if only they follow those simple rules...
Im not saying that XP is garbage, on the contrary, I think it brings some VERY interesting ideas like pair programming, and its test-planning.
what I AM saying, is: if you are considering to use XP you should be very careful and try to look at it with reason, rather than passion.
you should ask yourself at least this two questions:
1) "The problems I faced in my experience would be eliminated if I had followed the rules of XP?"
2) "The practices of XP would be enough to make my project a sucess?"
whatever is your decision, I guess we could call this a good start.
Wow, you got nasty fast.
So, you would like to know how a team should figure out what the interface between functional modules of their system should be?
Here's what worked for my team (Yes, I was the team lead, and, no, you're wrong, no one was fired, in fact the company took us to Atlantic City and then, dinner, to thank us for the work we did).
First, the team lead comes up with an overall design. He discusses the overall design with the team in a brainstorming session, and improvements are incorporated in the design. There may be arguments, but they're limited to this initial speccing out session.
The project is broken up into modules, and each module is broken up into function calls. The parameters and the return values for each function call are then agreed upon. You might say, "function foo will take three strings, fooey, hooey, and spam, and will return a properly formatted URL as a string." The programmers each take the modules they are most interested in. People agree on the overall plumbing, then go their separate ways with their modules, to code them without interference.
As each module is completed, it is integrated with the greater whole by the team lead. Debugging is done with driver programs and function stubs, and everything is separately unit tested. Programmers are responsible for their chunk of the system, and its interface. They don't have to put up with a lot of baloney like having to justify what they're doing to a partner who's looking over their shoulder. The overall design is handled by the team lead, who keeps an eye on how the individual modules are going together.
Modules can be built by internal staff, or by outside agencies. They can even be purchased and just integrated in. The point is that everything is modular, and everyone is responsible for his/her chunk, without interference.
Overall, this results in the least amount of argument, and the fastest overall forward progress because everyone is working in parallel, simultaneously. Projects can be completed very quickly at minimum expense if everyone pulls their weight.
I think that my point was that whenever programmers have to collaborate on a single stretch of code, they will inevitably disagree on implementation details and algorithms, and that this will lead to unproductive debate that will bog down a project. You missed the point entirely. For any given piece of code, there should be one programmer who writes it as well as he can without interference.
My joke about the Tao of programming was just a joke. But the basic idea is valid. Too many cooks spoil the broth. So you have one cook doing broth, another doing steak, another doing salad... And, the restaurant owner or head chef determines the menu.
Respond if you must. But I have said all I wish to say. You're too judgemental for my tastes.
Farewell! It's been a fine buncha years!
We had the exact opposite happen, actually. I was against the idea of XP when we first started using it at my previous company, but once we got into the swing of it, I grew to love it. It sounds like you guys weren't actually sticking to the XP very well.
You should have a lot of problems with pairs getting off-topic- that's the reason you have a coach. If your pairs are spending their time talking and going over estimates, somebody should step in. You should be having regular meetings to discuss estimates and figure out what will and won't get done, so I don't see how people can just go over like that.
You shouldn't grow expertise domains because two people are working on any given thing at once. If you're pairing with somebody and they start doing things that you don't understand without talking to you, you should stop them (and I don't see how non-XP processes would've done any better for you in this situation) and ask to drive so that they have to explain it to you while you code it.
Our bugs were significantly reduced because we always had more eyes designing, writing and looking over code. It's important that you not let people just go off and write one component over the course of two months or something. You should be focusing on small components done on a short schedule and constantly rotating people so that there's no code ownership.
Also, were you not doing good unit testing? That alone should bring your bugs down significantly.
It really sounds like your new system is just XP-lite... If you really stuck to XP I think it would save you a lot of time (no need for scheduling meetings and reviews) and get the same end results.
Another thing we tried at our old company was "demos" at the end of every phase (phases were two weeks) where we had to show and explain to the rest of the dev team what we coded that phase- this greatly reduced bad design and was akin to your peer reviews, but we just gathered up the whole dev team and spent a morning doing it. It sounded like a waste of time but it significantly helped, because everybody understood how every component of the system worked.
-- atomly
Clarification of the central paragraph:
I should have known better. Someone is already judging me based on paragraph II, so I'd like to state more specifically what was meant. Jesus, I should have known better.
Ok. It's my opinion that a solid design can best be reached by either one person working alone or a team lead who handles the overall design and breaks it up into subtasks for his team to handle.
It really comes down to what sort of political system you follow. If everyone is equal and there's no one directing the action, the result is anarchy. If there's centralized leadership, and everyone is doing their job and staying out of everyone else's hair, the result is harmony.
This lines up very neatly with system design.
A programming team where everyone's working on the same code is going to end up arguing about just about everything. Debugging is going to be a joke; nothing will be accomplished. Similarly, programming in pairs with one person coding and the other mouthing off is going to drive everyone crazy.
The basic idea I proposed was what has worked for me in the past: a central team lead breaks up the project into component parts, and programmers select the parts they want to complete. The group agrees on the plumbing and then scatters to do their work, everyone working in parallel. As each chunk gets completed, it is provided to the lead for integration. Chunks are unit tested with driver programs and function stubs.
the IDEA is, programmers end up working independently, following an agreed upon interface, and everyone can be happy and get along. Other benefits include:
1. Each module has a consistent coding style throughout.
2. Each programmer is responsible for his/her own module, so over time, they can respond to bug reports and so on.
3. Programmers can choose the algorithm they think is best, without having to sit around jawboning with their "partner" about whether this or that widget is the best to use. No one gets stressed out, and everyone is happy.
Anyway, we're getting away from the point. The point was, "too many cooks spoil the broth". So, the head cook has one cook doing broth, one cook doing the roast, another doing salad and so on. And, everyone can relax and just cook, instead of having to argue about whether they should add once pinch of salt or two.
Farewell! It's been a fine buncha years!
"You are obviously a very fluid writer, and not too bad at bragining either. I should imagine that you other skills have suffered because of this, though most mangers wouldn't notice and would probably take you out to lunch."
That's very nice of you to say, but I don't think that being a good writer and being able to bargain skillfully automatically means that my other skills suffer. Balance is important to me. I may spend most of my time programming, but on the side I keep up with mathematics, a little physics, literature... It keeps my mind sharp and prevents burnout.
As for managers taking me to lunch, well, I'm afraid that I'm not a particularly social person. I tend to keep to myself. Besides, I'm somewhat nervous about associating with managers. When managers decide they like you, they generally tend to try and make you into a manager as well. This reminds me a little too much of count dracula. He tried to promote people HE liked, too... So, I generally try to be invisible and avoid managerial notice.
Farewell! It's been a fine buncha years!
"player 4 hit player 1 with 0 stroms"
See, I held the same opinion before I started on an XP project. :)
/valued/ having the other person there.
/does/ make for a very definite improvement in code quality.
:)
But it ended up actually working out very well. Sometimes I was bored when I wasn't the one 'driving' actively, but I found something, in the long run: the only time I felt defensive about someone sitting right there watching me code was if I wanted to hurry through something to get home, or get to lunch, or whatever. The times I'd be writing 'well, I'll hack it now and clean it up later' code, which I would be ashamed to show someone.
The rest of the time, when I was sitting down to implement something or work on a design for an API, I found that I
I lost track of the number of times that someone might point out 'you've repeated that one sub-block of code with only a few variations across the past four tasks, let's refactor to make that a function itself' or could watch me program and point out a corner case I had not considered in what I was writing, or that I could do the same for them.
So, while I was pretty opposed to the idea of pair programming before using XP on a project, I got won over. I don't think it's some miracle cure that will fix everything, but I do now think for the right pairing situations it
To each their own.
--Rachel