|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| News | See Also | Recommended Books | Recommended Links | Recommended Papers |
| Testing | History | Humor | Etc |
I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me. Donald Knuth |
When it comes to ‘extreme programming' (XP) methodology I tend to be extremely skeptical. It looks like a "Viva Viagra" or worse "Vioxx" type of fad, more the symbol of complete corruption of a large part of academic community then anything else. At a basic level of analysis, Extreme Programming is not a technical methodology but something like a new management style + a mall technical cult which promotes it's own utopia. The number of zealots are significant and objective discussion is difficult to this very reason. and please be aware that there are a lot of books on Amazon that is graded 4 or 4.5 stars that are complete and utter nonsense. Actually authors who participated in propagation of this methodology should be treated in a special way and participation of any of those authors in other books is a sure warning sign. I actually do not see any of the authors I respect in the list. Amazon lists approximately 50 books in a search for the term.
At the same time critical book are a sure sign of presence of some level of courage. For example, Questioning Extreme Programming
XP was originated from the work of Kent Beck in Chrysler (Chrysler Comprehensive Compensation System payroll project) and the first book was published in October 1999. BTW Chrysler eventually canceled that project.
The most noise was in 2000-2003. After that it gradually faded and I did not noticed any books about it published in 2008. Probably was replaced with : "agile software development"... Wikipedia even mentioned that extreme programming is a now considered to be a form of "agile development" (that's an interesting term because opposite to agile is probably "stagnant software development :-) and this proximity gives "agile development" term bad breath despite some sound ideas in the agile manifesto (looks like plagiarism of open source software development methodology) IBM is very active in milking this cow via its Rational franchise:
In a keynote presentation and in correspondence afterward, IBM's Per Kroll, chief architect for IBM Rational Expertise Development & Innovation, cited the company's proliferation of agile practices among some of its approximately 35,000 developers.
"I think in general we have 1,000-plus people [using] agile in the IBM community," with an additional 2,000 persons trained in agile practices, Kroll said. He said, though, that he did not anticipate that all 35,000 developers would adopt agile.
On Monday at the conference, IBM's Scott Ambler, practice leader for agile development, spoke on the state of the agile space. Agile development focuses on developing software in iterations of usually two weeks. This allows for more flexibility than the traditional waterfall methodologies.
"Agile is taking many things that we’ve been using for a lot of years before agile was around [and] adding a lot of new things and putting a very good spin on it and making development more human," said Kroll. Concepts like iterative development and continuous integration are not new, but agile accounts for factors like human and collaborative aspects, he said. "We firmly believe, and our executives firmly believe, that the most successful organizations of tomorrow will be the ones [able] to adopt agile principles."
IBM has roughly 150 agile projects, he said. But each team needs to determine its own agile use based on their context. Agile means a lot of things to different teams, he said.
A key factor is that IBM helps customers and its own teams with applying agile complex environments, facing such issues as application complexity, scalability, and compliance issues, said Kroll.
It seems like XP is just rehashing the same idea as surgical team described in the mythical man-month but in some very incoherent and clumsy way ("pair programming", my God what a name -- "cluster disaster" would be much better). "Pair programming" may help to stop programmers from spending to much time reading Slashdot or searching Goggle for things that has nothing to do with the project :-). It might be even cause decline of revenue at eBay. However, they seem to be able to compensate for this in a lot of other ways :-)
While reading each other code is essential, collective ownership diminishes individual responsibility and deliberately creating huge communication overhead that diminishes each programmers productivity. For more talented members of the team it entails a dramatic drop ("state farm effect").
It's also very difficult to get the right balance of personalities in the teams. If you pair a good programmer with a zealot the zealot will be in a driving seat and the results will suffer. We all should periodically reread Brooks famous The Mythical Man-Month. The one will understand that XP does not bring anything new to the table. In essence this is a profanation of Brook's idea of surgical teams in a perverse way mixed with Microsoft idea "one programmer -- one tester". XP did not invent the "daily build" it was practiced by many organizations including Microsoft long before (I know NYC-based Information Builders used in since at least 1992), but made it popular.
In my opinion, extreme programming is extremely overrated. Some of the ideas, such as test-driven development (although this concept is not restricted to XP), work well. Others, such as pair programming just do not work in my opinion. Programmers like writers are solo beasts - putting two of these dragons behind one keyboard is asking for trouble.
As a methodology XP is pure fantasy. It has been well known for a long time that big bang or waterfall model. And it does not work well. The 'spiral' model (iterating out from the core of a small well understood system) is a much better methodology popularized by Unix and in some form reemerged in prototyping approach.
It is difficult to survive that amount of SE nonsense in a typical XP books. Readers beware.
Zealots defend XP "cluster disaster" as a kind of code review. But one computer and the same cubicle idea is nonsense. It is unclear to me that communication improves it people share the same cubicle. I like that is called Extreme because this is an example of extreme nonsense:
Sure, the name is some PR trick,
but it makes sense because this technique is a reaction to all those new trendy
development process in which (when you push them to the extreme) you are spending
90% of your time in meetings or drawing graphs and then the code is supposed
to magically write itself and work perfectly on the first build because this
technique is so well conceived.
Like any kind of engineering, software engineering needs as much face to face
collaboration as possible.
To a point collaboration is important, but real SE requires careful planning by
a talented architect and clear interface definitions. XP -- almost to the point
of being pathological -- attempts to avoid planning as much as possible by substituting
endless chatter and tremendous time wasting repeatedly re-implementing what could
have been done right the first time. (And yes, I know some things always have to
be reimplementation, but just because mistakes are inevitable doesn't mean they
have to be encouraged.)
Software engineering has an unfortunate tendency towards fanatical adherence to the latest fat that is always sold as a silver bullet. Usually, this involves an implementation language backed by a marketing push (Java); XP seems to be another programming fad built on unscrupulous books marketing (structured programming extremism and verification bonanza was the first). And like verification bonanza before it has found an abundant number of zealots may be due to its potential for snake oil salesmen to earn a decent living at the expense of programmers suffering form it.
But all or nothing is not just an XP problem. Most SE methodologies are close to religions in a sense that they all try to convince you that their way is best, if you deviate you are a heretic and if it all fails then it's your problem for not following the rules. The "prophets" that "invent" a methodology make their money from book publishing as well as teaching people how to do it. There are also a lot cluesee followers, lemming that believe everything that prophets preach.
And the last thing prophets need is some kind of objective analysis or critique. Why would they kill their cash cow even if they themselves understand that they are wrong? In general, SE methodology advocates, like cult leaders cannot afford to correct themselves.
|
|||||||
I also hate to offend other people’s sensibilities—given that software methodology has always been akin to religion. With the caveat that there’s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development, let me just say that almost everything I’ve ever heard associated with the term "extreme programming" sounds like exactly the wrong way to go...with one exception. The exception is the idea of working in teams and reading each other’s code. That idea is crucial, and it might even mask out all the terrible aspects of extreme programming that alarm me.
Bad Agile in More Detail
I've outlined, at a very high level, one company's approach to software development that is neither an Agile Methodology, nor a Waterfall cycle, nor yet Cowboy Programming. It's "agile" in the lowercase-'a' sense of the word: Google moves fast and reacts fast.
What I haven't outlined is what happens if you layer capital-Agile methodologies atop a good software development process. You might be tempted to think: "well, it can't hurt!" I even had a brief fling with it myself last year.
The short answer is: it hurts. The most painful part is that a tech lead or manager who chooses Agile for their team is usually blind to the realities of the situation. Bad Agile hurts teams in several ways.
First, Bad Agile focuses on dates in the worst possible way: short cycles, quick deliverables, frequent estimates and re-estimates. The cycles can be anywhere from a month (which is probably tolerable) down to a day in the worst cases. It's a nicely idealistic view of the world.
In the real world, every single participant on a project is, as it turns out, a human being. We have up days and down days. Some days you have so much energy you feel you could code for 18 hours straight. Some days you have a ton of energy, but you just don't feel like focusing on coding. Some days you're just exhausted. Everyone has a biological clock and a a biorhythm that they have very little control over, and it's likely to be phase-shifted from the team clock, if the team clock is ticking in days or half-weeks.
Not to mention your personal clock: the events happening outside your work life that occasionally demand your attention during work hours.
None of that matters in Bad Agile. If you're feeling up the day after a big deliverable, you're not going to code like crazy; you're going to pace yourself because you need to make sure you have reserve energy for the next big sprint. This impedance mismatch drives great engineers to mediocrity.
There's also your extracurricular clock: the set of things you want to accomplish in addition to your main project: often important cleanups or other things that will ultimately improve your whole team's productivity. Bad Agile is exceptionally bad at handling this, and usually winds up reserving large blocks of time after big milestones for everyone to catch up on their side-project time, whether they're feeling creative or not. Bad Agile folks keep their eye on the goal, which hurts innovation. Sure, they'll reserve time for everyone to clean up their own code base, but they're not going to be so altruistic as to help anyone else in the company. How can you, when you're effectively operating in a permanent day-for-day slip?
Bad Agile seems for some reason to be embraced by early risers. I think there's some mystical relationship between the personality traits of "wakes up before dawn", "likes static typing but not type inference", "is organized to the point of being anal", "likes team meetings", and "likes Bad Agile". I'm not quite sure what it is, but I see it a lot.
Most engineers are not early risers. I know a team that has to come in for an 8:00am meeting at least once (maybe several times) a week. Then they sit like zombies in front of their email until lunch. Then they go home and take a nap. Then they come in at night and work, but they're bleary-eyed and look perpetually exhausted. When I talk to them, they're usually cheery enough, but they usually don't finish their sentences.
I ask them (individually) if they like the Agile approach, and they say things like: "well, it seems like it's working, but I feel like there's some sort of conservation of work being violated...", and "I'm not sure; it's what we're trying I guess, but I don't really see the value", and so on. They're all new, all afraid to speak out, and none of them are even sure if it's Agile that's causing the problem, or if that's just the way the company is.
That, my friends, is not "agile"; it's a just load of hooey. And it's what you get whenever any manager anywhere decides to be a chump.
Re:Why is it called "Extreme"?
(Score:2) by Eivind Eklund (5161) on Tuesday September 19, @09:38AM (#16137298)
(Last Journal: Friday October 08, @05:53AM) The name comes from introducing some good practices and then doing them extremely ("Turning them up to 11", in the words of Kent Beck).
- "Don't let your programmers be tired" -> "Forbid programmers from working overtime".
- "Do code review" -> "Do code review in real time, by pair programming"
- "Test" -> "Test everything, immedately, by not writing code until you have a failing test"
- "Get customer feedback" -> "Release in very short cycles, and have a customer owner that decide how things should work"
- "Don't overcomplicate the code" -> "Delete all code and functionality we do not need today, and clean up all dirty code immediately"
Eivind.
by Anonymous Coward on Tuesday September 19, @10:17AM (#16137523)
You have some misspellings there... let me correct you:
- "Don't let your programmers be tired" -> "Forbid programmers from working overtime at your own peril as you should realize that a programmer is a real, live adult human being which happens to be a professional and therefore can take care of his own work hours due to the fact that he has been living with himself for quite a few years and knows perfectly well when he's tired and when he's not, and resents being treated like a child by a moronic idiot who just happens to have stepped on enough people to raise up the ladder enough to annoy said programmer".
- "Get customer feedback" -> "Release in very short cycles, and have a customer owner that decide how things should work in your dreams, because in the real world you should realize that your customer doesn't give a s***t about whether you need feedback or not, because he's already told you everything you need in all those prep meetings and impromptu emails, and just wants to sit back and click on the darned button and see things working, so he won't be looking or testing anything you send to him because "it's not done yet" until he thinks "it's done" and then he'll change all those lovely specs you spent some much time tuning the tests to fit into. And your manager will be so desperate to please him that he will say yes to anything he says, because after all, this is Extreme Programming, it's great, it's flexible, we can do anything as long as the tests come out alright, right?"
There, cleaned that up a bit for you.
JARCP
----
Just Another Random Cynic ProgrammerRe:buzzwords(Score:2)
by Ignignot (782335) on Tuesday September 19, @09:06AM (#16137132)
(Last Journal: Thursday October 07, @02:33PM)Seems like a lot of that is just rehashing the same old same old. What's wrong with the programming surgical team described in the mythical man month? Collective ownership seems to be deliberately creating more communication overhead for programmers. In other words, what does XP bring to the table that is useful instead of just different? by seti (74097) on Tuesday September 19, @07:34AM (#16136790)
In my opinion, extreme programming is extremely overrated. Some of the ideas, such as test-driven development (although this concept is not restricted to XP), work well. Others, such as pair programming just do not work in my opinion. Programmersare solo beasts - putting two of these dragons behind one keyboard is asking for trouble.
(Last Journal: Friday July 01, @09:48AM)
Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer. Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.Others, such as pair programming just do not work in my opinion. Programmersare solo beasts - putting two of these dragons behind one keyboard is asking for trouble.
Where have you been the last 20 years? The stereotypical programmer, hacking his piece of kernel over night is very endangered species, and rightly so. Like any kind of engineering, software engineering needs as much face to face collaboration as possible.Programmersare solo beasts
(Score:4, Insightful)
by Angst Badger
(8636) on Tuesday September 19, @08:20AM (#16136934)
Pair programming can be seen as a kind of code review, but with the reviewer
in equal position with the programmer. Traditional code reviews tend to be frustrating
for the programmers, because the reviewers are in position of authority.
I've never seen one of those. Every code review I've participated in has been
a collaborative effort between peers. If you treat a code review as a cooperative
effort between programmers, it doesn't have to be frustrating.
Like any kind of engineering, software engineering needs as much face to
face collaboration as possible.
To a point. But real engineering requires planning and clear interface definitions,
and XP -- almost to the point of being pathological -- attempts to avoid planning
as much as possible by subsitituting endless chatter and tremendous time wasting
repeatedly reimplementing what could have been done right the first time. (And
yes, I know some things always have to be reimplemented, but just because mistakes
are inevitable doesn't mean they have to be encouraged.)
Software development has an unfortunate tendency towards fanatical adherence
to the latest silver bullet. Usually, this involves an implementation language
backed by a marketing push; XP seems to be the first programming fad built entirely
on book publishing. But then, no implementation language ever actively encouraged
the kind of passive-aggressive personality that thrives on XP.
by g2devi (898503) on Tuesday September 19, @09:01AM (#16137108)> Pair programming can be seen as a kind of code review, but with the reviewer in equal position with the programmer.
It depends on the personalities. It likely works well if you have a uniform team, but it you have a diverse team (which is a good thing since your weeknesses are compensated by someone else's strengths), it can be very suboptimal. For instance, if you put a reflexive analytical introvert with a shoot from the hip intuitive extrovert, the extrovert will more than likely steamroll over most of the input of the introvert and feel validated because the shoot from the hip extovert thinks that the code has the approval of the reflexive analytical programmer.
In the case of a code review, the reflexive analytical introvert gets to do things the way he/she wanted to do and gets input during the review from the extrovert if there are alternate ways of doing things. More than likely, it's also learning experience for the shoot from the hip programmer to program more safely. In the reverse case, the shoot from the hip intuitive extrovert gets to do things the way he/she wants and gets validation that that code is safe and handles all conditions. It's also likely a learning experience for the reflexive introvert to see that "crazy new techniques" can actually be better.
Uh-oh (Score:2, Funny)
by jbellis (142590) * <jonathan&carnageblender,com> on Tuesday October 07, @12:32PM (#7154709)
(http://www.carnageblender.com/)That's almost as bad as reviewing a book titled "Linux isn't always the answer."
Absolutely Hopeless and Clueless (Score:3, Insightful)
by mihalis (28146) on Tuesday October 07, @12:35PM (#7154747)
(http://www.mihalis.net/)The Previous Extreme is pure fantasy. It has been well known for a long time that big bang or waterfall models don't work well. For example see the Ian Sommerville Software Engineering book - it's mentioned the 'spiral' model (iterating out from the core of a small well understood system) for at least ten years. I couldn't read any more of this "book review" after such a bunch of nonsense.
Re:Absolutely Hopeless and Clueless (Score:5, Insightful)
by AJWM (19027) on Tuesday October 07, @01:05PM (#7155027)
(http://www.ajwm.net/amayer/)Q: What do you get when you combine the waterfall model with the spiral approach?
A: The flush model.
On a more serious note, the waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development, and where reliability of the final product is critical. This assumes you have the resources (time and people) to do it properly -- and this is why the waterfall method has gotten a bad reputation -- it's been applied where there is insufficient time/resources or the requirements aren't well understood.
Most business applications, for example. The waterfull method is wonderfully suited to something like spacecraft control software, where the spiral approach (we called it "stepwise refinement" twenty-five years ago when I was in college -- there's nothing new) just wouldn't work. But businesses are both constantly changing and adaptable -- a business app that only implements half the requested features is probably still more useful than not, where as software to control complex hardware that's only half done is nearly useless (except that some testing can be done, perhaps).
As always, it's a matter of picking the right tool for the job, rather than picking up your hammer and treating everything as a nail.XP wouldn't meet DO-178 requirements... (Score:1)
by Svartalf (2997) on Tuesday October 07, @03:08PM (#7156214)
(http://svartalf.freeshell.org/)Which is required for any piece of aviation (including spacecraft) flight control system that is not on an experimental plane.
It doesn't make for the stringent design specification requirements, let alone a few others.
I definitely do NOT want to be flying on a plane or having one fly over my head that doesn't meet the DO-178 certification.Re:Absolutely Hopeless and Clueless (Score:2)
by hawkestein (41151) on Tuesday October 07, @07:03PM (#7158463)...the spiral approach (we called it "stepwise refinement" twenty-five years ago when I was in college -- there's nothing new)...
The spiral approach and stepwise refinement aren't exactly the same thing, although they are both iterative approaches. As I recall, stepwise refinement is a top-down design technique. You basically start by implementing the top-level of the system, and you put in stubs for the lower level. Then, you gradually work your down the abstraction ladder, implementing the lower level components, until you're all done.
On the other hand, the spiral approach is really all about risk management. At each iteration, you're supposed to identify and address the most significant risks in the project. This doesn't necessarily mean you're using a top-down approach, although it might.Re:Absolutely Hopeless and Clueless (Score:2)
by AJWM (19027) on Wednesday October 08, @11:33AM (#7164143)
(http://www.ajwm.net/amayer/)Well, top-down programming is just called top-down programming. It's an idea that sounds good in theory, and helps in decomposing problems. However, if you're not careful, at the low levels you end up with a serious mismatch between your design details and the available APIs and libraries.
At each iteration, you're supposed to identify and address the most significant risks in the project.
Most significant risk, or that which gives you the most functionality for a given effort (bang for the buck)? Depends how you define "risk" and "functionality", I suppose.
Re:Absolutely Hopeless and Clueless (Score:1)
by Tablizer (95088) on Tuesday October 07, @08:57PM (#7159212)
(http://www.geocities.com/tablizer | Last Journal: http://slashdot.org/~Tablizer/journal/)On a more serious note, the waterfall model does work for certain problem domains, notably those where the requirements are well understood in advance and unlikely to change significantly over the course of development,
Those are the ones most likely to be outsourced overseas.Re:Absolutely Hopeless and Clueless (Score:2)
by AJWM (19027) on Wednesday October 08, @11:38AM (#7164229)
(http://www.ajwm.net/amayer/)Those are the ones most likely to be outsourced overseas.
Heh. Good point, at least for commercial apps.
I'll get really nervous when that starts happening for military and aerospace stuff (the sort of thing that's all written in Ada).A place for everything (Score:3, Interesting)
by DaveAtFraud (460127) on Tuesday October 07, @01:17PM (#7155142)The "waterfall" was great for determining exactly what the user wanted but then ended up delivering it five years later after the requirements had changed.
"Use-case" analysis was great for determining how the user would interact with the system but tended to automate the existing processes instead of figuring out how automation could make the process unnecessary.
OO was great for implementing the non-reusable objects determined to be needed by "use-case" analysis (see previous item).
Too many shops implement XP as an excuse for not understanding the user requirements but just bashing out a bunch of high quality code that solves *the wrong problem* in a short amount of time. This isn't a criticism of XP so much as a criticism of the way it is misused (as has every other innovative software development technique).
The basic problem is and always has been that inventing the future is difficult mainly because the future has a habit of changing while we're busy trying to invent it. No technique other than a time machine will ever solve this problem because it is inherent in the invention process.Re:A place for everything (Score:1)
by israfil_kamana (262477) <israfil@gmx.net> on Wednesday October 08, @10:47AM (#7163524)So what you're saying is that the bottom line is:
(wait for it)
Solid judgement based on experience, and an evaluation of the circumstances of the project at hand?
Wow... coooooool. It only that weren't such a bloody revolutionary idea. Mindless applications of processes and methodologies is bad. Clue? Mindlessness. Creating a quality artifact requires judgement, experience, thoughtfullness, analysis, consultation, colaboration, and estimation. All of these are the products of experience.
I propose a new methodology, which I shall designate the SANE-M. It requires that you start learning, fail a lot, learn from your mistakes, find mentors, learn from them, go off and be extreme and youthful, fail some more, learn some hard practical lessons, then, after about five to ten years, start doing projects with a flexible mind, having exposed yourself to a wide variety of project types, styles, personalities, funding levels, timescales, etc. You are likely to evolve your own project-specific method in colaboration with other experienced participants, and such a project is likely to succeed (if it has all the required ingredients to succeed). A baker who has never made pumpernickle will probably screw it up even if he has a recipe.
Wait! Method re-name. The new name should be "Life" or maybe "Professionalism".
Re:A place for everything (Score:2)
by DaveAtFraud (460127) on Wednesday October 08, @02:09PM (#7165653)Solid judgement based on experience, and an evaluation of the circumstances of the project at hand.
It must be revolutionary otherwise more people would be doing it! Management keeps looking for a way to not have RFC 1925 apply to their particular pet project because, if it does, it will cost too much and take too long. The evangelists for each new methodology always sell it as a "silver bullet" that will circumvent RFC 1925. No one has come up with one yet and my bet is that there isn't one.
Re:Absolutely Hopeless and Clueless (Score:2)
by mihalis (28146) on Wednesday October 08, @01:51PM (#7165511)
(http://www.mihalis.net/)How many systems has written and/or designed Ian Sommerville?. Sure, he may have written books and articles, but, is he anything more than a theorist?. I think this doesn't matter - as I remember, this was backed up with a lot of supporting material in the references, so it wasn't just him and it wasn't just academic sources.
The practical development is very different than the theoretical. Linux kernel is developed in a special flavour of XP, and it works fine, is very modular, scalable,... though it has it flaws. The fact is XP works in a lot of cases.
I'm not saying anything against XP. I'm just saying that the review starts off by saying that the status quo before XP was big-bang/waterfall development model. My response is : no it wasn't!!
Sommerville is just a quotable, checkable source. If you want something from personal experience in industry, I worked on a submarine command system for the UK Royal Navy. This project started in the 80s some time, and was designed in phased releases of working systems with increasing capabilities and performance. Sure it's not XP, but it's not a big bang nor waterfall either.
Re:What the hell are you talking about? (Score:2)
by mihalis (28146) on Wednesday October 08, @02:11PM (#7165668)
(http://www.mihalis.net/)I'm talking about the book review as posted on slashdot. Here is the first bit of it (emphasis mine):
The Previous Extreme - What XP Set out to Fix
It had previously been accepted practice to spend months (years, even, on large-scale projects) gathering requirements, then another year or two on design, before a single line of production code had been written. The infamous "big bang delivery" occurred when this gigantic monolith of a software system was finally delivered to the customer, only for the customer to retort that this was nothing like what he wanted.
It was also accepted practice to divide the system into separate subsystems, and attempt to integrate them after several months. By this time, each subsystem would have taken on a life of its own, and integrating these disparate monoliths together gave a whole new meaning to "plug and pray."
How XP "Fixes" It
These statements about "accepted practice" are factually wrong since at least the mid-80s, probably earlier. XP follows on and improves upon from several, probably dozens of earlier fads all of which attempted to get away from the monolithic system design disasters.
Now, if the reviewer had said "a common mistake is" I wouldn't have had a problem!
Ask Slashdot: Have you used Extreme programming (Score:3, Interesting)
by kilroy_hau (187226) on Tuesday October 07, @12:37PM (#7154766)
(http://pub59.ezboard.com/belforosinnombre | Last Journal: http://slashdot.org/~kilroy_hau/journal/)Well, have you?
I'm about to start a project using pair programming (not exactly Extreme, but something like that) and I don't like it one bit
Pair programming is uncomfortable on our reduced space. And it's noisy.
Are the inconveniences worth it?
Re:Ask Slashdot: Have you used Extreme programming (Score:4, Insightful)
by bokelley (563370) * on Tuesday October 07, @12:46PM (#7154844)I would have to say that pair programming isn't really worth it. I personally can't stand the lack of productivity that is inherent to having two programmers sit around and watch each other type.
My version of pair programming is to have one developer write a test harness while the other one develops the actual code to be tested. This forces each of them to communicate with each other, generally via a very informal spec or direct communication with the client.
This ties two people closely together with the immediate need, but it doesn't require complete overlap. I'm not convinced that two brains are better than one - typing is an inherently blocking process, and whiteboarding happens either way.
Anway, what good hacker wants to watch someone else type? Or play a game? Or do anything? Coding isn't a spectator sport.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Interesting)
by pong (18266) on Tuesday October 07, @01:02PM (#7155000) (http://slashdot.org/)I think that is an incredibly simple and extremely powerful idea!! Sometimes when you have been programming for a while you just need the mental rest you get from working on your own. I think that the next time I feel like a break while pair programming, I will try to suggest to my pair-programming partner that we split up and one of us focus on the tests while the other is doing the production code.
I think it could be especially useful when you are working on a problem that you are not really sure how to solve. The one person can write a test suite, which is a really good way to work out the most flexible and useful interface, while the developer does some prototyping/sandboxing.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by bokelley (563370) * on Tuesday October 07, @01:10PM (#7155080)Right. Also, I forgot to mention how incredibly important it is to switch between being the tester and being the coder. If you don't do this then it's too easy for both parties to be lazy, and there's no way to check or enforce the quality of code.
At my current job, I've actually outsourced the implementation of the tests (because we're a very small shop) but I'm making the product manager the only interface with the test developers. This keeps me honest, and has the "nice" side effect of making me document all of my interfaces and APIs since the other developer isn't even in the office.
One benefit of doing this with two programmers on-staff, as I prefer, is that when somebody leaves a project, there shouldn't be a huge drop in knowledge. I left a project a few months ago that was done this way and the remaining programmer, who was quite junior, was able to keep on going without much trouble since she had been exposed to both the testing and development aspects of the project.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Interesting)
by nullard (541520) <nullprogram.voicesinmyhead@cc> on Tuesday October 07, @02:31PM (#7155832)
(Last Journal: http://slashdot.org/~nullard/journal/)At my current job, we have three developers. We work on projects as a group, on three seperate machines near each other.
The steps we follow:
- We are all involved in project design.
- One of us writes up the requirements.
- The others review it.
- Two of us write the code while the other designs tests.
- The tester tests the system then works with the coders to fix the problems.
- Repeat last step until the bugs are gone and the project is ready for beta
- Beta testers test.
- All three developers work on the final bug fixes
The client approves a demo app after step 3. The client approves the beta version before the testers see it. The client is involved in beta testing.
This system seems to work well for us. The 3-way version of pair programming is beneficial to stringent testing. The fact that we use our own machines (but are free to walk over to any of the other developers) lets us parallelize the development project. Since adopting this system at the suggestion of our manager, our turnaround time has dropped dramatically. Aditionally, our code is better before we hit the beta stage. The last project we did had almost no bugs turn up in beta. The constant black box testing durring development followed by white box testing and fixing before the beta ensured that the code was really good before the testers saw it.Ask Slashdot: Have you used Extreme programming (Score:5, Insightful)
by bunratty (545641) <crown2@ziplip.com> on Tuesday October 07, @01:10PM (#7155075)The point of pair programming is not to force programmers to communicate with each other. Pair programming is "the knob turned to 10" on code reviews... if code reviews are good, then do them all the time, as a programmer is first writing the code.
If you don't do pair programming, you need to replace it with a less extreme version of code reviews, such as simply reviewing each patch before it is checked in. The type of pair programming you describe involves no code reviews, and therefore is no substitute for pair programming.
Re:Ask Slashdot: Have you used Extreme programming (Score:2, Interesting)
by bokelley (563370) * on Tuesday October 07, @01:14PM (#7155110)That is a good point. I forgot to mention the other important part of this, which is that people switch roles often on the same component. This is my version of turning the dial up to 10. If you think about it, the point of a code review is to make sure that code is clean and legible (and more or less efficient) so that maintenance is easier. What better way to do this than force people to modify each others' code on a regular basis?
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by daecabhir (166667) on Wednesday October 08, @08:31AM (#7162093)There is another advantage to the process that you have described... it is easier to implement for teams that for a variety of reasons cannot work physically together. However, by rotating the responsibility for the test harness and the coding of the application, it would appear that you do get a fair amount of benefit. Thanks for the insight!
Two idiots don't make a genius (Score:2)
by Ars-Fartsica (166957) on Tuesday October 07, @01:51PM (#7155480)
(Last Journal: http://slashdot.org/~Ars-Fartsica/journal/)Pair programming attempts to take two mediocore programmers and create one decent programmer out of them. No senior developer is going to put up with some malodorous jerk sitting on his lap asking questions about every line.
Two idiots make a nice pair of twits (Score:1)
by Demodian (658895) on Tuesday October 07, @03:00PM (#7156125)Unfortunately, two mediocre programmers yield nothing but crap code. For pair programming to work well, the two would have to be very balanced with regards to each other's performance, or else there will be more work done by one or the other.
No "sane" senior developer is going to let a junior programmer coast along on the same coding task without doing his/her fair portion of the work. I find that it to be a waste of time to have someone standing there watching me code unless I am intentionally trying to demonstrate or teach. (Especially the boss!)
Besides, the parrot should sit on its own perch...Re:Two idiots don't make a genius (Score:3, Insightful)
by royalblue_tom (557302) on Tuesday October 07, @03:16PM (#7156308)Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.
Perhaps this way, the code will be commented, have tidy layout, and be readable. Meaningful (to more than one person) variable names might be used. Boundary checking done. Good test cases written, and used. Other programmers may be able to work on this code at a latter date. The code may do what was specified (for this particular task) as the one programmer keeps the other one focussed on the job in hand.
If the developer is *that* senior, he should be capable of explaining what he is doing to the lesser minds in the company. Treat it as a mentor slot. And of course, that's only for 50% - the other half of the time is watching the other guy, advising, perhaps teaching, and guiding.
The question the developer should ask himself, "Is he really a malodorous jerk, or am I so socially inept that I am unable to work with people who may not be as skilled as I am?".Re:Two idiots don't make a genius (Score:2)
by tshak (173364) on Tuesday October 07, @04:25PM (#7157043)
(http://slashdot.org/~tshak/)Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.
Perhaps this way, the code will be commented, have tidy layout, and be readable. Meaningful (to more than one person) variable names might be used...
It's called having people in charge of managing your code. A good software manager will dictate certain code rules, layout guidlines, etc. If I try to check in a bunch of hacked code with crazy variable names and crappy or no comments, it'll get rejected and it'll never make it to the main source tree. If I do this often enough I'm off the project, and eventually out of a job. There's no reason a $50K - $100K+ software developer should need someone watching over their shoulder to do a good job.Re:Two idiots don't make a genius (Score:2)
by tigga (559880) on Tuesday October 07, @04:46PM (#7157299)Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.
That's exactly the same as two mediocre programmers equal one decent
;)) Perhaps this way, the code will be commented blah blah blah
Perhaps you don't need to pay to second programmer to do this - you just need a secretary for each programmer..
Two Hackers doesn't make an omelet (Score:2)
by arth1 (260657) on Tuesday October 07, @08:59PM (#7159235)
(http://2130706433/)Nope, pair programming takes two hackers and attempts to turn them into one disciplined programmer.
That's as futile as trying to create a diciplined heavy metal band or porn star. It defeats the whole purpose of having a Hacker in the first place.
The correct way to use two Hackers is to appeal to their ego. Have both code the same piece concurrently, and let the best code win. That way, you both ensure that the coders do their very best, and you also get alternative backup code BEFORE a problem is reported, which is invaluable in troubleshooting. Program crashes with both pieces of unrelated code? Chances are the problem is elsewhere, or with the specs.
Oh, and you can use this competitiveness to your advantage with QA too -- encourage the coders to find problems with each other's code. If possible, keep the programmers from even seeing each other (it's easier to slam the code of someone you've never met), and don't penalise the coder who creates bugs, but reward the finder instead.
THAT's extreme programming. EP, for people who can both code and spell.
Regards,
--
*ArtRe:Two Hackers doesn't make an omelet (Score:2)
by royalblue_tom (557302) on Thursday October 09, @01:27PM (#7174830)You weren't planning on working with one of these hackers again were you - as he'll hate you for not choosing his "brilliant" code over the other hackers. Why do I get the feeling that I will get two programs, neither readable by my other programmers, uncommented or documented (I had to get it done quicker than the other guy), and the bugs will be nasty and obscure.
I used "hacker" in my post to mean someone who churns out code, without worrying about the niceties of software engineering. Someone who is likely to think that having uncommented and undocumented code is a good thing, as it keeps him hired. For every dedicated "coding standard" programmer, you'll find a legion of these "hackers" who feel that their code is self commenting, self documenting, and its obvious what it does. They don't need to follow the company standard for indenting or variable/method naming because they use their own "better" method. But their code is just a full of bugs as everyone else's, and more difficult to maintain.
Pair them up. Let their egos shame each other into writing one "decent" piece of code, rather than two hacked pieces of indicipherable cack. The software industry is a team game these days. Programers need to learn to work together - both in the way they interact with others, and how they write code.
And hey, most heavy metal bands are very diciplined in their performance - and they match their performance to that of the other players in the band, working together to perform a single piece of music.Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by rowanxmas (569908) on Tuesday October 07, @03:14PM (#7156292)Why isn't the knob turned to "11" ?
And no, its not your dial that's wrong.Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by blakestah (91866) on Tuesday October 07, @03:19PM (#7156338)
(http://www.keck.ucsf.edu/~dblake)Programming is inherently a solo act. Pair programming is not only less efficient, it is 4 times less efficient. Every time you interrupt a programmer's train of thought you are losing time more certainly than when he picks up his Coke for a drink. XP pair programming is an incredibly stupid idea, which is why no one NOT ASSOCIATED with XP ever gives it a positive third party review. If you try it, well, sorry to hear that, but if you try it, you will NEVER want to pair program again.
Also, refactoring can be good, but it takes a lot of time and effort to make code cleanly work, and that effort is usually duplicated when you re-factor. The cost in time is HUGE, and it should not be taken lightly.
Re:Ask Slashdot: Have you used Extreme programming (Score:2, Insightful)
by iroberts (672505) on Tuesday October 07, @06:15PM (#7158115)Pair programming is not only less efficient, it is 4 times less efficient. Every time you interrupt a programmer's train of thought you are losing time more certainly than when he picks up his Coke for a drink.
I've done some pair programming, and I have to disagree here. It's true that the "passenger" will interupt the "driver", but it will not necessarily interrupt the train of thought. Indeed, frequently comments will be along the lines of "why not just do instead?". Moreover, the "passenger" can often help keep track of the big picture, allowing the "driver" to focus on details without getting lost.
This is not to say that pair programming is perfect. For certain drudge work, it's definitely not efficient. Even with two coders who respect each other and get along well, it can be very emotionally draining. But I've almost never felt that my pairing partner and I could have developed *and debugged* code more efficiently by working separately. Indeed, we tended to write remarkably bug-free code when we had a "second pair of eyes".
One thing that I think is necessary for pair programming to work well - both developers need to be as "egoless" as possible. Only when each person can truly listen to and fairly evaluate the others comments while in "the heat of battle" will pair programming work well.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by William Tanksley (1752) on Tuesday October 07, @06:47PM (#7158364)
(http://dolphin.openprojects.net/Omega)4 times? Cite your source, please. The rest of that paragraph seems equally unlikely (I've seen positive reviews of PP, including one positive study), but I'll let that float until I get a backup to that number.
Also, refactoring can be good, but it takes a lot of time and effort to make code cleanly work, and that effort is usually duplicated when you re-factor. The cost in time is HUGE, and it should not be taken lightly.
You're confusing refactoring with rewriting, aren't you?
-Billy
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by blakestah (91866) on Tuesday October 07, @11:41PM (#7160300)
(http://www.keck.ucsf.edu/~dblake)4 times? Cite your source, please.
Just devel times at one site, depending on whether the programmers were paired or not. The pair takes twice as long as a single programmer, which is four times the man hours.
Maybe for debugging it is a smarter idea, but I doubt it.
You're confusing refactoring with rewriting, aren't you?
No, I've had to refactor before. But when only one of the pair thinks a refactor is necessary, a warning bell oughta ring.Deafening (Score:1)
by CarlBenda (645559) on Tuesday October 07, @10:10PM (#7159775)Having "the knob turned to 10" gives you a sense of what pair programming is like. After a week or so at 10 you can't hear much and so it goes with code reviewing. Watching someone type is one of the most boring things to do after watching grass grow. After a while you lose focus and start to drift off. I've seen it plenty of times with multiple partners. In some cases simple coding gets so boring both the person doing the coding and the person checking fall off. Switching between typing and watching only helps a little. Switching partners help a little also. At the end of the day though you start hating programming. That's life at 10.
Re: Pair programming at 10 (Score:1)
by mfnickster (182520) on Tuesday October 07, @11:40PM (#7160292)
(http://profiles.yahoo.com/mfnickster)It comes down to doing it in the most reasonable manner for any pair of programmers. Sometimes you can work in tandem, other times you need long breaks from the other guy.
You don't necessarily have to have one programmer literally looking over the other's shoulder-- in my experience, it's more natural and makes more sense to discuss the problem with the other programmer, work separately for a while and then meet again to go over the results.
In one case, another programmer (senior to me) was describing how he was getting stock quote information over the wire and handling the fractions using floating-point calcs. He didn't like the implementation or the performance very much, and while he was telling me this, his phone rang.
While he was on the phone, I looked over his code and a few minutes later when he hung up, I handed him an integer version. By working on the problem alternately, we came up with a better solution (and the senior put in a good word for me with the boss, saying I had "a good eye for optimization)."
It all depends on what you're used to and what you're willing to try as a fresh approach.
Re: Pair programming at 10 (Score:1)
by CarlBenda (645559) on Tuesday October 07, @11:54PM (#7160353)Sounds great to me. This just happens to not be pair programming and XP. You don't work separately for a while because if you do that the other person isn't checking your code. If they aren't checking your code you need QA. If you need QA then why are you wasting another programmer's time. Etc, etc, etc. I find plenty of things in XP that I like and have used for years well before the word XP came out. The problem with XP is it decided to make these things ridged and cranked up to 10. Some thing that was good in moderation has been made into an ugly way to manage software development. Hopefully pair programming doesn't keep the bad connotation that XP is giving it.
Re: Pair programming at 10 (Score:1)
by mfnickster (182520) on Wednesday October 08, @12:11AM (#7160431)
(http://profiles.yahoo.com/mfnickster)I have to admit that I've never tried XP (I worked as a programmer before it came along), and I've only read a little about it. You're right, my example is not XP (I didn't mean to imply that it was), but it is pair programming of a different kind.
Two programmers, working on the same problem, in the same capacity-- the essential point being that the code passes both sets of eyes before it goes out. In our case, it didn't have to be checked every 5 seconds; every 5-15 minutes was sufficient.
The principle is the same, but tuned to accommodate our working style.
Re: Pair programming at 10 (Score:1)
by CarlBenda (645559) on Wednesday October 08, @07:06AM (#7161681)Don't get me wrong either. Pair programming has for me been some of the best times of my life. Working with someone I respect and getting near instant feedback after I've done something was great. It's just not what XP advocates. Doing it all the time with everyone leads to more problems than it solves.
I don't think the principle is the same with regards to XP pair programming and what you describe. You don't check after 5-15 minutes in XP. The person pairing with you is suppose to watch all the time looking for errors. There is one keyboard. One computer. There is pretty well nothing else to do for one person in the pair except to look over the other person's code. The principle in XP is constant vigilance. Looking the other way for 15 minutes allows your partner to run amok.
:-) I think you are developing an agile style. I like agile methods. You are not doing XP.
An analogy with XP would be drinking red wine. Red wine is good for you. XP would say dial that up to 10 and drink a few bottles a day. XP drops the context that some things work well in restricted situations and just says you should do it all the time with everyone.
Imagine working with someone in your group that you don't really like and whose code while "right" doesn't look too good to you. Go ahead and pair program with them. If you are lucky maybe you'll change your opinion about them. If you aren't tough luck under XP. Now do the same with someone you do like. With luck you'll still like them at the end of the day. Some times people aren't compatible but can work together. With XP you aren't really suppose to pick and chose. If you do you lose out on spreading the code knowledge.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by ebh (116526) * <mailto:ebh-slashdot@hypePASCALrreal.org%20minus%20language> on Wednesday October 08, @08:34AM (#7162128)
(Last Journal: http://slashdot.org/~ebh/journal/)Pair programming is "the knob turned to 10" on code reviews.
As a sound technician, I know that turning the knob to 10 isn't necessarily what you want. Take an ugly sound and turn it to 10 and you now have an ugly, loud and distorted sound.
As a kernel programmer (being a good instance of a system where no one person can know everything), I know that the best code reviews are done by teams of engineers who look at the code from different points of view.
In addition to people who can easily find common coding errors, you also want people who can spot locking and semaphore problems, backwards-compatibility breakage, subtle interactions with other subsystems, use of deprecated interfaces, etc.
If I'm a file system programmer paired up with another file system programmer (because we're doing file system work), then we're liable to have a lot of the same blind spots, so there are whole classes of bugs that can leak through.
"Thank you for finding that off-by-one error. Now I know that the spinlock I'm holding forever is the correct one."
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by chromatic (9471) on Tuesday October 07, @01:14PM (#7155103)
(http://wgz.org/chromatic/)I would have to say that pair programming isn't really worth it. I personally can't stand the lack of productivity that is inherent to having two programmers sit around and watch each other type.Non sequitur. Your first sentence talks about pair programming. Your second sentence talks about something that is almost entirely unlike pair programming.
Pair programming is "Hey, let's talk about this problem and write some code as we're going along!", not "Hey, sit behind me and shut up unless I make a typo!" If someone's made you do the latter and called it "pair programming", he was quite wrong.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by bokelley (563370) * on Tuesday October 07, @01:20PM (#7155184)There are definitely situations where that works, and I have had good experiences with that. However, I would separate out "pair designing" and "pair debugging" from "pair programming".
When I run into a problem, it's always nice to discuss it with someone. I like that. I don't need to be forced to "pair program" to have these conversations. Similarly I don't need to "pair program" to help other people solve their problems, often interactively. What I don't like about pair programming as a methodology is that it hides incompetent programmers, reduces the learning that comes from failing at a certain approach, and discourages leaps of faith.
Re:Ask Slashdot: Have you used Extreme programming (Score:2, Insightful)
by chromatic (9471) on Tuesday October 07, @01:30PM (#7155284)
(http://wgz.org/chromatic/)What I don't like about pair programming as a methodology is that it hides incompetent programmers, reduces the learning that comes from failing at a certain approach, and discourages leaps of faith.I'm not sure I follow your reasoning.
How does pair programming hide incompetent programmers? If you're switching pairs often, everyone will have the chance to work with everyone else.
Do you prefer a learning style that requires everyone to make the same mistakes? In my teams, I prefer not to make mistakes at all. In practice, I'll settle for making a mistake once then letting everyone know what it was and how to avoid it. Given experienced programmers, it's pretty handy to start down a path and have your pairing partner say, "Wait... we did something like this before. Here's how we solved it then."
I don't know what you mean by "discourages leaps of faith" at all. That sounds like a positive thing to me. I'd rather go by the empericism of the test suite than mystical intuition that can't be verified. XP's pretty firmly in the realm of "solving the customer's actual problems" than any Kierkegaardian philosophy.
Admittedly, I'm a fan of pair programming. I've used it on a couple of projects and plan to use it on several more in the future.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by Cederic (9623) <mailto:slashdot@UglyFatGu[%20]rg%20['y.o'%20in%20gap]> on Tuesday October 07, @03:35PM (#7156507)>> it hides incompetent programmers
Actually, it exposes them quicker, as their incompetence becomes immediately apparent to their partner.
Further, it gives the partner an opportunity to improve them and reduce their incompetence.
If that doesn't work, then they're hopelessly incompetent, and you're no worse off than had you not programmed (and indeed, much better than if you'd found out 8 months into development when you did your first code review)
>> reduces the learning that comes from failing at a certain approach
Actually, it increases the learning - that learning is spread around the whole team in short order. The team learn collectively from their failures, instead of each individual having to make them all in turn.
>> and discourages leaps of faith.
I'm not sure what you're getting at here. I have been sat with a partner while he's said "go with me on this one for ten minutes, I want to try something". I shut up, I watch, I learn, I see how he's intuitively solved a problem or implemented a mechanism and saved a ton of work.
Or I've been driving, and I've asked my partner, "I know we should methodically trace through this bug, but I reckon I can find it by guesswork - gimme a couple of minutes to have a go". Two minutes later, bug fixed, several hours of painful tracing averted.
It's about building good communication within the pair, in having faith in each others abilities. What you've been describing is not pair programming.
~Cederic
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Funny)
by Nept (21497) on Tuesday October 07, @01:31PM (#7155287)
(Last Journal: http://slashdot.org/~Nept/journal/)except if one programmer doesn't like slashdot, it will make the other more productive...
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by bmj (230572) on Tuesday October 07, @01:34PM (#7155328)
(http://anklebiter.net/)I would have to say that pair programming isn't really worth it.
It's certainly not worth it all the time, but there are times when it can boost productivity. Let me first say I've never worked in a pure XP environment, but on several projects we've cut & pasted from XP and used what works well for us.
Pair programming can work well when you're still developing the logic that will drive the application. Why? Because at that point, you're not coding for 8 hours straight. You're coding a bit, running some tests, then tweaking. If you work well with your partner, you've constantly got a sounding board for ideas, and chances are, you'll crack the egg sooner rather than later. Sure, you could both work on the same problem space separately and compare notes at the end of the day, but I think had you been working together, the problem would have been solved much sooner.
Although it's not a pure XP situation, pair programming works quite well when you've been handed someone's else code. While working on a particular project, my group was handed code from the client for a sub-project that they had completed, but were unhappy with (they were not a development shop by trade), so suddenly we were responsible for righting the wrongs. It was VB app (and we were doing web development for them, and we weren't VB specialists), and we gave them a fairly conservative time estimate. The manager wasn't particularly happy to see us working in pairs (didn't seem productive) but we got the sub-project completed well under budget.
My version of pair programming is to have one developer write a test harness while the other one develops the actual code to be tested. This forces each of them to communicate with each other, generally via a very informal spec or direct communication with the client.
I like that idea.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by stew1 (40578) on Tuesday October 07, @04:00PM (#7156789)
(http://www.alacpp.org/ | Last Journal: http://slashdot.org/~stew1/journal/)What you describe isn't [good] pair programming.
When you're *really* doing pair programming, you and your partner are talking constantly and shoving/grabbing the keyboard back and forth between each other. Most programmers are familiar with "flow" or "the zone" or "hack mode" -- alive in the code and dead to the world. When two people are in "pair-flow", the results are astonishing. It takes a lot of work and management to get two people to that level of intellectual comfort, but it's worth it. I'm not doing pair-programming currently, and I miss being able to plug my brain into my former colleagues'. Achieving pair flow makes up for any lost productivity inherent in halving the number of things a team is working on (and there are actual university studies which show that pair programming makes up for initial productivity hits in the long run, due to a lower bug rate).
One problem with pair programming is that it's intellectually and emotionally exhausting, especially for your average introverted programmer. One of the places where XP needs to be refactored is in giving coders a chance to rest and recuperate while still on the job. The Sustainable Pace practice counteracts this to a certain extent, but not fully, in my experience.
The other poster is wrong when s/he claims that pair programming isn't about increasing communication. In fact, that's one of the largest benefits. Fred Brooks showed that communication overhead is indeed the essential problem of team programming. Pair programming lets you skirt around Brooks' Law, in certain situations.
JonRe:Ask Slashdot: Have you used Extreme programming (Score:1)
by JohnwheeleR (662355) on Tuesday October 07, @05:09PM (#7157560)XP was developed because consultant programmers found requirements change frequently regardless of the solidity of upfront design schematics. Why? Hell if I know. Maybe it's because programming is a new disipline. Maybe it's because clients can't forsee all they want without interacting with something. I don't know. I do know that working months on something, showing it to a client, and them hating it sucks (especially when it meets the requirements you worked out with them). It sucks to go for months after deployment adding new features and refining others. It is painful, leaves the codebase in a convoluted state, and makes programmers and clients resentful of one another.
XPs principles make it easier to cope with changes. It doesn't completely throw out the notion of an upfront design; however, it stresses we constantly improve the design while we code (design and implementation are concurrent activities). That's why pair programming makes sense to me. Group dynamics and synergy maximize the quality of a design.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by CrazyWingman (683127) on Tuesday October 07, @05:17PM (#7157640)
(Last Journal: http://slashdot.org/~CrazyWingman/journal/)Actually, yes, pair programming does have its place. I'm writing a compiler right now with a couple of teammates for a class, and there are just certain parts where it REALLY helps to have someone looking over your shoulder. I mean, when your writing regexp's for a scanner it's REALLY easy to mess something up, and can be rather difficult to find it.
I won't argue that it definitely takes some getting used to. I, like everyone else, am someone who would rather go off and code on my own and then review the code later. I don't like having someone say "hey, you forgot a semicolon there" right after I hit enter. Chances are I realized it too, and will be hitting backspace in the next half second to correct it anyway. But, this is something that a pair has to work out. There is work to be done getting used to both the typer and the watcher positions.Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by bokelley (563370) * on Tuesday October 07, @05:35PM (#7157782)I can totally see that - makes a lot of sense. I guess my point is that if you're not doing intricate develoment, then it's a waste of time.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by sbrown123 (229895) on Tuesday October 07, @12:47PM (#7154856)
(http://slashdot.org/)Yes, its worth it. Take two programmers: one more skilled then the other. Give the less skilled one the keyboard. Force the skilled guy/girl to have to communicate all typing through the less skilled guy/girl. Less skilled guy/girl not only gets a good understanding of what went into the code (they typed it) but also learns new things from the smarty. Eventually you have two smarties. Repeat.
Who hates the idea of pair programming? Smarties ofcourse. They dont want to lose what they feel makes them special. They are bad for business anyways.Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Horny Smurf (590916) on Tuesday October 07, @12:54PM (#7154909)
(Last Journal: http://slashdot.org/~Horny%20Smurf/journal/)smarties aren't smarties because they write good code. They write good code because they're smarties.
I think Brookes (Mythical Man Month) claimed a 50 x difference between the best programmers and mediocre programmers. Do you really think having joe superprogrammer dictate code to joe retard is going to help joe retard's skills?
I think you should take a refresher course in economics. Focus on the "division of labor" part.Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Theodrake (90052) on Tuesday October 07, @01:20PM (#7155188)The problem is we need to get rid of those mediocre programmers. But too many government projects depend on body count to get a profit. To many managers depend on having large staffs to get promoted. Until the U.S. government will let a company charge a 40 - 50% markup and use 1/5 the staff on a project it ain't gonna happen.
Re:Ask Slashdot: Have you used Extreme programming (Score:3, Insightful)
by Don Calamari (144891) <thedon AT doncalamari DOT com> on Tuesday October 07, @01:03PM (#7155006)
(http://doncalamari.com/)How true. Everybody knows the most profitable companies are run by drooling troglodytes. I'm just kidding, I'm sure you mean the prima donnas who nobody can stand...
Anyway, I've found you simply cannot get 2 good coders by shackling one good and one poor coder together. The bad one generally doesn't learn anything and the good one just gets frustrated and angry.
Pair programming might work if the poor coder had a desire to learn, but it's been my experience that this usually isn't true. Learning to be a good coder does not happen by proximity and osmosis.
It's all about *which* two coders you have... (Score:2)
by Anonymous Brave Guy (457657) on Wednesday October 08, @07:04AM (#7161675)Learning to be a good coder does not happen by proximity and osmosis.Perhaps not, but it does happen when you take someone with potential and a willingness to learn, and then apply proximity to skill and experience and let osmosis do its work.
Not every junior programmer wants to make that effort, but plenty do. A smart company will employ such people and train them properly: it's a much cheaper way of getting good results, it raises the standards across the industry by supporting the new starters who will be the senior programmers of tomorrow, and it gives both an incentive and a watch on the veterans to make sure they keep sharp. Basically, everybody wins.
Sure, if you hire monkeys this will never get them anywhere and will just be a drain on the senior guys. But that's true of any methodology you use. The moral of the story is to hire people with enthusiasm for their field and a desire to learn, and not the monkeys. If they cost a bit more, pay it; compared to the benefits to a development team, the modest rise in remuneration and occasional perks it will take to make your place stand out from the crowd are nothing.
(I should say here that I don't advocate "pure" pair programming. I do, however, believe in senior programmers being heavily involved in supporting the junior guys by various means, including variations on the pair programming theme.)
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by geoffspear (692508) on Tuesday October 07, @01:10PM (#7155073)
(http://www.geoffreyspear.com/)Wouldn't it be better for a project to get rid of the bad programmers and let them go off and learn how to code for themselves, instead of having a good programmer dictate code to them?
Most people, I think, can type their own code a lot more efficiently then they can dictate code to someone else. Unless they learned to code using some sort of voice recognition system instead of a keyboard.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Bigbaz (678814) on Tuesday October 07, @01:14PM (#7155107)We've been using a modified XP process at work for a little over 2 years now, and I've got to agree with you on the benefits of pair programming. It is difficult at first to give up control of the keyboard, and at first I felt a little strange telling someone else how they should do something. Generally, I'm a hands on kind of guy, I would rather just do something myself than have to explain to someone else why they should do it and how to do it.
That said, I have really come around, and now I love pair programming. The newer people in our group get to learn from us, and we get to make sure they learn our way of doing things. We also learn from them, when they bring new ideas and methodologies and such. Plus, when we do our designs, we've got two sets of eyes making sure everything is covered, and to make sure we adhere to our design. And we know the code is good, because we've got two developers looking at it all the time.
Not to say it's a perfect world, of course. We still have conflicts and disagreements and all that, and scheduling time to work with a partner is difficult when everyone is so busy, but we get it done, and I believe the product is superior to what we put out before.
No development process will be a perfect fit in every organization and situation, just like no stock $OPERATING_SYSTEM distribution will suffice for every application. You try it, you learn what needs to be changed, and you change it. Then you keep changing it as you go along.Re:Ask Slashdot: Have you used Extreme programming (Score:5, Insightful)
by AJWM (19027) on Tuesday October 07, @01:18PM (#7155155)
(http://www.ajwm.net/amayer/)Who hates the idea of pair programming? Smarties of course. They don't want to lose what they feel makes them special.
More likely they're just driven insane by having to wait on the other person. Depends on how bad an impedence mismatch you have. Programmer productivity can vary by an order of magnitude or more between individuals (so called "superprogrammers", although the term is silly). If you have one of the latter, no amount of "skill transference" is going to bring the former up to the same speed, any more than teaming someone with an IQ of 150 with someone with an IQ of 110 is going to raise the latter's IQ to 130. (It might, through frustration, lower the former's though;-)
On the other hand, if you're just talking about a couple of average programmers, one of whom has a couple of years more experience, then yeah, it makes sense.
They are bad for business anyways.
Depends. Nobody needs prima donnas, of course (well, except ballet companies, I suppose;-) but do you just want a stable of predictable but average programmers, or do you want to hold on to those "smarties" who, in a pinch, can deliver good code faster than any eight other programmers put together?
(Of course, you may not have the choice. Superprogrammers aren't nearly as prevalent as the number of average programmers who think they're "super" would indicate;-)
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by WotanKhan (150429) on Tuesday October 07, @02:07PM (#7155631)
(http://www.offlinetshirts.com/)More likely they're just driven insane by having to wait on the other person
Exactly. If skill transfer is the goal, there are much more efficient ways of going about it. Personally, I am a blindingly fast typist, and I do my best developing in sort of a flow state where I am coding nonsequentially and moving around within the environment with the agility of a video game. I don't see achieving this in a pairs environment.
On the flip side, I learn best by starting with a well designed, fully realized and functional product, cloning it and modifying it to do something else. Some explanation and documentation from the developer is always great, but there is nothing like reading good code. Trying to communicate code via speech is just a recipe for frustration, not efficient learning.
Oh Yeah? (Score:2)
by blunte (183182) on Tuesday October 07, @04:11PM (#7156912)Nobody needs prima donnas, of course (well, except ballet companies, I suppose
;-)
Not this prima donna [foxnews.com]
Sorry, OT, couldn't help myself:) Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by CarlBenda (645559) on Tuesday October 07, @10:15PM (#7159810)I pair programmed with a kid who got a math degree from Caltech and spoke three languages. Definitely very smart. Context though is everything. Smart at what? This kid couldn't program worth shit. He smelled which made things worse to pair with him. After a while I got off on telling this "smart" guy we needed another test. He fell for it all the time and our productivity with it. I consider myself a good programmer. You don't have to be "smart" to realize a dumb move. The "smart" guys are the ones who will stick with a stupid move no matter what.
Give me five people who program well and have code reviews. You'll get tons of code out of a well working team because producing code that's good makes them feel special.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by AJWM (19027) on Wednesday October 08, @11:51AM (#7164486)
(http://www.ajwm.net/amayer/)Interesting anecdote, but your point was...?
You'll get tons of code out of a well working team
Sure, that's well documented in studies of software engineering economics. So is the fact that in a field like programming, there can be an order of magnitude difference in productivity between two individuals. If you have people like that, you're better off organizing the team like Mills' "Chief Programmer Teams" (what Brooks calls "Surgical Teams").
I don't think anyone has investigated whether that difference correlates with being a smelly polyglot mathematician in either a positive or negative sense. I rather suspect it doesn't correlate at all. My guess, though, is that high IQ helps, but is not the sole predictor. (I know plenty of high IQ people that can't program their way out of a paper bag, so to speak.)Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by Paradise Pete (33184) <listcatcherNO@SPAMfastmail.fm> on Tuesday October 07, @01:20PM (#7155178)
(Last Journal: http://slashdot.org/~Paradise%20Pete/journal/)Eventually you have two smarties. Repeat.
They are bad for business anyways.So then your business process produces things that are bad for business?
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by pgrdsl (713039) on Tuesday October 07, @01:45PM (#7155417)The best pair programming occurs when you have two equally skilled people whose skill sets overlap but aren't the same.
The worst is when one of the pair is a chimpanzee and the other is expert: you end up with a confused chimpanzee and a suicidal expert. Oh, and no code.
I find pairing works for short stretches, followed by periods where the members of the pair can wander off, do a bit of solo coding/thinking/design, and then join up again when appropriate.
Successful pairing is not a student-teacher relationship - it is best when it is a joining of equals. If you want "teaching", send them on a course.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by TrekCycling (468080) on Tuesday October 07, @03:20PM (#7156350)Nevermind the fact that you often have people (usally the smartie, in my experience) who think their way of typing, running the IDE, the keyboard, etc. is the ONLY way and that any lack of efficiency is terrible and you can develop a REALLY bad programming environment. I've been on the other end of that. A perfectly competent programmer with some amped-up developer behind me who can't stand the slight inefficiencies in the way I operate the computer (not talking about actual code, but I don't use keyboard shortcuts enough or multi-task quite well enough). That can be very stressful and... frankly... silly.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by doinky (633328) on Tuesday October 07, @03:45PM (#7156629)Fabulous. So now our profession is nothing more than short-order fry cook. No possibility of turning on the headphones and going into the zone. No chance of browsing the web for new and interesting por^H^H^Hstuff.
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by dubl-u (51156) * <mailto:0301310758@p%20o%20t%20a%20.%20to> on Tuesday October 07, @04:49PM (#7157348)
(http://pota.to/)Give the less skilled one the keyboard. Force the skilled guy/girl to have to communicate all typing through the less skilled guy/girl.
This happens some in pair programming, but it's not the only way to do things. I'd say I spend maybe 5% of my pairing time dictating something. More common is when the person who knows whats going on seizes the keyboard and says, "Let me show you what I mean."
My general rule of thumb is that they keyboard should change hands every 10 minutes or so. Otherwise it's too easy for the driver to forget about the navigator, or for the navigator to zone out.Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by adamruck (638131) on Tuesday October 07, @01:30PM (#7155282)You are wrong, sorry. Programming in pairs is fundamentally better then programming alone. My computer science teacher once showed our class a movie clip of a basketball team practicing, he told us to count the number of times they dribbled the ball. We all did our best to count. When the movie was done he asked us if we noticed anything odd. We all said no. He played back the tape, turned out a big fuzzy bear maskot walked through the court. None of us noticed becuase we were all so focused on the counting. The partner catches the bear becuase when you work with partners you dont work on the exact same block of code. If you have a good partner you can accomplish some amazing coding.
I dont know about that whole learn through pair programming thing though. Sounds sketchy to me.Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by richieb (3277) <`rbielak' `at' `acm.org'> on Tuesday October 07, @02:31PM (#7155826)
(http://www.netlabs.net/~richieb | Last Journal: http://slashdot.org/~richieb/journal/)I'll tell you - people. no-one wants someone looking over their shoulder, you even want your guru to just sod off for a bit and let you try stuff out yourself.
Wait until you have to write some that has to be 100% solid when it's installed at your biggest customer site. Then you will want about 5 people looking over your shoulder checking what your write.
The other plus to pair programming is that there is another person that really knows the code, so you can take long lunches and vacations.
Re:Ask Slashdot: Have you used Extreme programming (Score:1)
by doinky (633328) on Tuesday October 07, @03:48PM (#7156668)If pair programming becomes required; don't we both have to take our long lunches and vacations at the same time?
Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by richieb (3277) <`rbielak' `at' `acm.org'> on Tuesday October 07, @04:54PM (#7157404)
(http://www.netlabs.net/~richieb | Last Journal: http://slashdot.org/~richieb/journal/)I think XP programmers are promiscous, so they can pair with more than one partner. Hmm..... this gets worse and worse...
by tcopeland (32225) * <tom AT infoether DOT com> on Tuesday October 07, @12:52PM (#7154886)
(http://tomcopeland.home.mindspring.com/)> Pair programming is uncomfortable on our
> reduced space.
Sounds like someone needs to provide your team with pair programming-friendly space. A wide desk is a start.
> And it's noisy.
What's noisy? The space you're in? The other people? The person you're pairing with?
> Are the inconveniences worth it?
Those inconveniences aren't intrinsic to pair programming. Don't give up yet...Re:Ask Slashdot: Have you used Extreme programming (Score:2)
by kilroy_hau (187226) on Tuesday October 07, @03:31PM (#7156468)
(http://pub59.ezboard.com/belforosinnombre | Last Journal: http://slashdot.org/~kilroy_hau/journal/)It's noisy beacuse you have to talk all the time to the other person.
Imagine several teams of pair programmers, all in a reduced space, all talking about their particular task at the same timeRe:Ask Slashdot: Have you used Extreme programming (Score:1)
by tcopeland (32225) * <tom AT infoether DOT com> on Wednesday October 08, @06:58AM (#7161652)
(http://tomcopeland.home.mindspring.com/)> It's noisy beacuse you have to talk
> all the time to the other person
Hm. Yup, pair programming definitely implies a lot of interaction with another person.
> all in a reduced space
This seems to be the problem.
> all talking about their particular task
> at the same time
I think this ends up being a bit of a good thing - if you hear me talking about
the Frob and how it doesn't have a getFiddle(), it's easy for you to pop up and
say "I just added one!" or whatever. Improved communication... good stuff.
Re:Ask Slashdot: Have you used Extreme programming (Score:5, Funny)
by pmz (462998) on Tuesday October 07, @12:52PM (#7154887)Pair programming is uncomfortable on our reduced space. And it's
(Score:1)by
aadvancedGIR
(959466) on Tuesday September 19, @08:09AM
(#16136897)
Agile software development is simply a way to say "code now, we'll get you the specs later"