Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Beck and Andres on Extreme Programming

ScuttleMonkey posted about 8 years ago | from the not-terribly-extreme dept.

321

narramissic writes "In recent years, Extreme Programming (XP) has come of age. Its principles of transparency, trust and accountability represent a change of context that is good not only for software development but for everyone involved in the process. In this interview, Kent Beck and Cynthia Andres, co-authors of 'Extreme Programming Explained: Embrace Change,' discuss how XP makes improvement possible."

cancel ×

321 comments

Sorry! There are no comments related to the filter you selected.

FP FTW!! (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16136758)

n/t

Re:FP FTW!! (-1, Flamebait)

Anonymous Coward | about 8 years ago | (#16136768)

suck me xtream pussy!

God! This is boring CRAP !! XP is dead, not aged (-1, Flamebait)

Anonymous Coward | about 8 years ago | (#16136943)



God! This is boring CRAP !! XP is dead, not aged. Who submits this couldn't-care-less spittle ??

Extreme... (4, Funny)

celardore (844933) | about 8 years ago | (#16136767)

I was hoping for something a little closer to Extreme Ironing. [extremeironing.com]

That would have been cool.

Re:Extreme... (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16136783)

Or even (shudder) Extreme Accounting:

http://www.extreme-accounting.com/ [extreme-accounting.com]

Re:Extreme... (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16136796)

Extreme accounting looks fun!

Not as fun as extreme-watching-paint-dry.com though.

Re:Extreme... (-1, Offtopic)

remembertomorrow (959064) | about 8 years ago | (#16136851)

Oh man, I've never laughed so hard in my life.

My lungs and stomach hurt now, thanks a lot.

Re:Extreme... (2, Funny)

pnone (1003781) | about 8 years ago | (#16137181)

There is also one good tool called Petra supporting extreme programming prototyping http://petra.cleverlance.com/ [cleverlance.com] We use it and love it.

Article's dated 6th May 2005.... (2, Insightful)

popeyethesailor (325796) | about 8 years ago | (#16136778)

This is too extreme even for slashdot...

Re:Article's dated 6th May 2005.... (1, Interesting)

Anonymous Coward | about 8 years ago | (#16136799)

I spent large parts of the 80's programming with a salesman sitting behind me saying things like "You've spelt that wrong" or "that won't work" or "why are you doing it that way?"

As far as I'm concerned, if anyone ever suggests I should program in pairs with someone again, I'm going to reach for my flamethrower.

Re:Article's dated 6th May 2005.... (2, Funny)

gbjbaanb (229885) | about 8 years ago | (#16136833)

I don;t know about that - I think pair programming is great. think:

What do you need to pair progam? development software, check. monitor, keyboard, check. coffee, check. newspaper check.
Right, divvi that up between the pairs evenly, you get the software and PC, I get the coffee and newspaper. See how pair programming works? :-)

Re:Article's dated 6th May 2005.... (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16136888)

That's gotta be the most boring item on Slashdot all month.

Overrated (2, Insightful)

seti (74097) | about 8 years ago | (#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.

Re:Overrated (1)

Ed Avis (5917) | about 8 years ago | (#16136813)

'in your opinion'... how many times have you tried it?

Re:Overrated (1)

joshetc (955226) | about 8 years ago | (#16136835)

He clearly states 'in my opinion' not 'in my experience'.

Re:Overrated (5, Interesting)

Spicerun (551375) | about 8 years ago | (#16136945)

I worked under it for at least a year. Its another one of those methods that looks good on paper, but sucks in practicality. What's unpracticle?

1. No company in their right minds wants to pay for TWO programmers to do a single job. But then, again, you can always get 2 programmers at half-price to do the job (and have half the quality of one full price programmer).

2. As with any other method, it assumes all the specs and implementation have been worked out before the code is even written....nobody has the freedom to write experimental throwaway code to even see if their approach is even feasible in the coding, or, if programming a device, if the device will even work with the approach being made (for you people not in the embedded world, most device datasheets are incorrect and seldom get corrected).

3. While its great at letting the mundane functions be rewritten (refactored) as many times as possible, it gives a mechanism where newer features are *always* put off (by managers usually) indefinitely....its an illusion, under a few managers, that the programmers will ever get to implement the newer features wanted by customers (its amazing how most new features are always rated as low priority by someone other than the customer....even more amazing about how many 'stories' aren't written by the customer.).

4. Even in the XP books it is explained that XP is not meant to work for every single software environment/situation....yet there are managers who will do their best to try to force it to work when it won't.

I always find it really is better for a group of Programmer Peers to sit down together and review the code AFTER it has been written (with tests). Trouble is, most companies/managers refuse to understand that 'Programming Peers' do not include the stock boy in shipping.

Just my $.02. Can you tell I didn't really like being under the XP model myself?

Re:Overrated (5, Insightful)

hclyff (925743) | about 8 years ago | (#16136838)

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.
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.

But when you put two programmers with equal authority, you have one thinking about the bigger picture and the other reviewing his mind flow. At the same time the later is writing down the ideas in code, with the first one reviewing his code as he types.

Programmersare solo beasts
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.

Re:Overrated (2, Insightful)

BiggerIsBetter (682164) | about 8 years ago | (#16136842)

Like any kind of engineering, software engineering needs as much face to face collaboration as possible.

You really think XP is Engineering?

Re:Overrated (1, Insightful)

Anonymous Coward | about 8 years ago | (#16136950)

Yup. People make a mistake when they try too much to base software engineering on other engineering disciplines, and copy the practices over intact. Successful engineering is not defined by the scaffolding used to build a product; it's defined by successful products. Saying that XP isn't engineering because it eliminates much of the scaffolding (documentation, big-design-up-front) from traditional waterfall processes is missing the point of engineering altogether.

I imagine the same response from old-school manufacturers, responding to Toyota's lean manufacturing model that we learned about in the 80's. No inventory? You consider this real manufacturing?

Re:Overrated (0, Insightful)

Anonymous Coward | about 8 years ago | (#16136951)

Open your eyes. XP when followed properly is a form of software engineering. I'm not going to waste my time explaining what engineering is to you when you can easily look it up for yourself. I'm a Computer Engineer and have recieved great praise from more traditional engineers due to my skills and abilities compared to traditional IT. Engineering is a set of tested princibles and codes of ethic applied to a given field.

Re:Overrated (5, Insightful)

Peter La Casse (3992) | about 8 years ago | (#16136971)

You really think XP is Engineering?

It's an attempt to achieve a greater level of quality through process/practices, which is as close as "software engineering" has gotten to real engineering so far. Arguably, though, "software engineering" isn't real engineering until you use formal methods to ensure the correctness of your design and implementation.

Re:Overrated (1)

aaribaud (585182) | about 8 years ago | (#16137246)

Sorry to ask, but can someone give an example of a field of "real engineering" which uses formal methods to ensure correctness, and of the formal methods used?

Re:Overrated (1)

MobyDisk (75490) | about 8 years ago | (#16137029)

If it isn't engineering then you are doing it wrong.

I recommend Extreme Programming Refactored [slashdot.org] if you are interested in taking the best parts of extreme programming and mixing them with a traditional waterfall approach to make a nice form of "moderate programming."

Re:Overrated (0)

Anonymous Coward | about 8 years ago | (#16137044)

It is if you can get it to work.

Re:Overrated (4, Insightful)

Angst Badger (8636) | about 8 years ago | (#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.

Re:Overrated (1)

Eivind Eklund (5161) | about 8 years ago | (#16137234)

Have you actually tried XP? Because to me, what you write sounds like somebody that hasn't tried it, and just feel that this can't work, and passive-aggressively accuses those that have tried it and found it to work of being passive-aggressive ;)

Re:Overrated (1)

njdj (458173) | about 8 years ago | (#16137022)

Traditional code reviews tend to be frustrating for the programmers, because the reviewers are in position of authority.

That's because most organizations don't know how to run code reviews properly.

For example, the reviewers should not be in a position of authority. Their role is to raise issues with the code. How to resolve those issues is entirely at the discretion of the programmer. Whether an issue requires any action at all is the programmer's decision.

Most programmers want to do excellent work, and will use the comments from the review to improve their code. If you have a programmer who does not want to do excellent work, the whole exercise is pointless - but if you have a programmer who does not want to do excellent work, you are in trouble in any case.

Re:Overrated (1)

g2devi (898503) | about 8 years ago | (#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.

Re:Overrated (2, Insightful)

Aladrin (926209) | about 8 years ago | (#16136841)

I mostly agree. However, you've forgotten that not all programers ARE like that. Some do actually work well when that close to someone else. I would love to find another programmer of my level (too much higher or lower would cause many problems, I'm sure) and try it. I suspect I'm too hard-headed-control-freak to allow someone else to do things while I just watch, even half the time. But there are people who can and DO do pair-programming and produce code faster, with fewer mistakes.

Unit testing is my new best friend, btw. It has helped me find so many issues and even prevent issues that I can't exist without it now.

Re:Overrated (1)

recordMyRides (995726) | about 8 years ago | (#16137005)

The other advantage is that you spend less time reading /. when there's another person sitting next to you.

Guess I ought to get to work. . .

Re:Overrated (1)

Aladrin (926209) | about 8 years ago | (#16137043)

That's an advantage? I'm doing something wrong then...

Re:Overrated (0)

Anonymous Coward | about 8 years ago | (#16137159)

Unit testing is my new best friend, btw. It has helped me find so many issues and even prevent issues that I can't exist without it now.

"new best friend"? "can't exist without it now"? What in the seven hells were you doing before?

I suspect you're the type of programmer who would benefit very much from pair programming -- one who has no idea what the hell he should be doing, and needs a nursemaid to watch your every move.

Re:Overrated (2, Interesting)

Eivind Eklund (5161) | about 8 years ago | (#16137217)

It actually works good even with a large experience/skill disparity between the programmers. I've only had the experience from the senior perspective - the juniors have said it worked well for them too. As they're still my friends (even though I've quit working with them), I believe them :)

Eivind.

Re:Overrated (1)

Scarblac (122480) | about 8 years ago | (#16136850)

You often see arguments like this... I like this part, I think that part doesn't work well...

The XP books make very clear that it's either all or nothing. They don't claim that pair programming by itself is always useful, they just claim that this whole set of techniques taken together is useful. If you're going to do all the other things XP says, XP says you should combine it with pair programming.

If you're not using all the elements (on-site client, pair programming, collective code ownership, etc etc etc), then you're not doing XP.

Personally I think pair programming greatly boosts performance, if only because it usually stops them procrastinating on Slashdot.

Re:Overrated (2, Interesting)

CastrTroy (595695) | about 8 years ago | (#16137006)

Pair programming may stop people from wasting time on slashdot, however, they seem to waste time in a lot of other ways. Like whether a specific for loop should be written as for(i = 0;imyArray.length();i++) or as for(i = 0;i=myArray.length()-1;i++). That and whether the opening brace should be on same line following the for statement, or on the next line. Oh, and whether certain things should be put in functions, or put inline in the code. Peer programming, while I can see the advantages of having someone sitting there, watching you, and correcting you as you go along, also has a lot of downsides. I often program in a very non-linear way. Sometimes i'm aware that I've made a mistake, but finish typing out my entire thought before I go back and correct it. Whenever I have someone watching me, and they point out the mistakes, telling me to go and correct something, I often lose my train of thought. It's like to writing a story and having somebody make you go back and correct all the grammar mistakes before while your done trying to get your thoughts out.

Re:Overrated (1)

ClosedSource (238333) | about 8 years ago | (#16137120)

I've had similiar problems with it. It's also very difficult to get the balance of effort right. If you pair someone who has strong religious beliefs about the "right" way to do things with another who is more flexible, it ends up being more efficient to let the religious one "drive".

Re:Overrated (1)

TheRaven64 (641858) | about 8 years ago | (#16137214)

Like whether a specific for loop should be written as for(i = 0;imyArray.length();i++) or as for(i = 0;i=myArray.length()-1;i++).

I don't know what language you are using, but it almost certainly shouldn't be written that way unless you are performing an operation in the loop that changes the number of elements in the array. Unless your language allows you to specify that the length() function is a pure function (and all other array methods you use are, then you will be testing the length of the array every iteration. If your framework supports iterators / enumerators then you should be using these instead; ideally via a 'for each' language construct or macro.

Re:Overrated (1)

Stooshie (993666) | about 8 years ago | (#16137219)

You should have coding standards in place where that kind of thing is sorted out before coding starts anyway.

Re:Overrated (1)

raduf (307723) | about 8 years ago | (#16137227)


    It's a matter of relationship. Last time (a long ago) when i did pair programming it was lots of fun and very useful. The one writing code took care of the micromanagement and had in mind at most the function he was working on, and the other was two steps ahead. If the side man keeps checking syntax and formating then the whole thing is useless.

Good marketing (2, Insightful)

ClosedSource (238333) | about 8 years ago | (#16137085)

"The XP books make very clear that it's either all or nothing. They don't claim that pair programming by itself is always useful, they just claim that this whole set of techniques taken together is useful. If you're going to do all the other things XP says, XP says you should combine it with pair programming."

This is just good marketing. By making this "all or nothing" claim, XP has a built-in excuse that you are invoking here. Ever noticed that you hear the phrase "because you're not doing it right" more often with XP than with other approaches?

Re:Overrated (3, Insightful)

blowdart (31458) | about 8 years ago | (#16137092)

But all or nothing is not just an XP problem. All methodologies say 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 people that "invent" a methodology make their money from teaching people how to do it, why would they kill their cash cow by telling people they should just take the bits that work for them? Methodology advocates, like preachers cannot afford to have people think for themselves.

Re:Overrated (1)

TechnoBunny (991156) | about 8 years ago | (#16136872)

I disagree. Most programmers have, at some point or another, had an 'OMG - why on earth did I do that?' moment. You simply dont get them with two sets of eyes on each line. In effect, you're getting not only line by line code reviewing going on, but its happening in the context of those lines being written. The code only gets committed if *both* developers are happy - and that is a sure way to increase the quality of code, since the foibles of an individual are subsumed.

Re:Overrated (2, Insightful)

ClosedSource (238333) | about 8 years ago | (#16137145)

"Most programmers have, at some point or another, had an 'OMG - why on earth did I do that?' moment"

Sure, but the question is what percentage of the time does this happen and is it often enough to justify tying up two programmers all the time.

"The code only gets committed if *both* developers are happy - and that is a sure way to increase the quality of code, since the foibles of an individual are subsumed."

That's an idealistic view. It would be more accurate to say the code gets committed when the more aggressive developer is happy.

Re:Overrated (1)

aadvancedGIR (959466) | about 8 years ago | (#16136885)

I tried a few work modes and I agree. What I consider to work best is to code solo with a main reviewer who participate to the conception phase, checks everything you deliver (code, docs and test plan) and is able to pass the test (and to correct crical bugs if you are on vacation). This way you get most of the advantages of pair programming but without the worst drawbacks: the reviewer knows what he is talking about and usualy gives far better comments than the random external reviewer and since everyone has a clear responsibility, no one can leech and get away with it.

Re:Overrated (1)

darkchubs (814225) | about 8 years ago | (#16136917)

haha I recall being in a "team pair" and the who ever was doing the typing (AKA: the hot seat).. was doing cart wheels through a land mine farm. Should he forget a { or ; then .. the other guy would yell it out as if we were playing pictionary... and it became EXTREAMLY ANNOYING. Programmers can be kinda .. well catty

Re:Overrated (1)

StrawberryFrog (67065) | about 8 years ago | (#16136930)

Programmers are solo beasts

Really? So what percentage of major, important or commonly used programs were written by only one person?

Re:Overrated (2, Interesting)

Peter La Casse (3992) | about 8 years ago | (#16136942)

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.

Test driven development is seductive; who wouldn't want to have all those automated tests in order to check changes to their code? However, I find it hard to put into practice. When requirements change frequently (which XP is supposed to be geared towards) it's hard to complete the tests much less complete the code before we're asked to change something, and changing even a small piece of code often requires changing a lot of tests. If you can offer any suggestions about how to improve that, I'm all ears.

Pair programming, on the other hand, is something that I wish I could have done when I was fresh out of school and not really as smart as I thought I was. It seems like an effective way to show the newer programmer how the veteran does things, both in the code and in how the day is scheduled.

Re:Overrated (1)

ClosedSource (238333) | about 8 years ago | (#16137164)

It seems to me that test driven development is a great way to generate throw-away code. Writing solid unit tests after you have written the code, provides the same benefits as writing it before except you don't have to write as many incremental tests.

Re:Overrated (0)

Anonymous Coward | about 8 years ago | (#16137241)

Except, of course, that at the end, you usually are neither given the time to create the tests nor the opportunity to run them.

What XP tries to do, with its "whole-shebang" methodology, is to build in safeguards in the process so that neither managers nor programmers can avoid them - thus the "pair programming == code review" - "ooh, cheaper and *on* time" says the manager, "oooh, only 50% of my time spent wasted on reviews" thinks the programmer - test-driven development, "whoa, tests that proves that the code works!" from the programmer, "finally no darn test phase that people want to spend *weeks* on" from the manager.

It is a nifty trick, because the intention is to allow for radical improvement of both efficiency and pleasure of work. That said, many of XPs particular tips can be used seperate from XP as a whole.

Do remember that the choice is not always between "unit-tests" and "test periods", it can be between "unit tests" and "no tests."

XP can work as an excuse to be able to do good work. While one could say "well, change workplace then!" that is not something that is viable or possible for everyone.

Re:Overrated (1)

Rungchen (628145) | about 8 years ago | (#16136965)

I agree that it is, as any 'great' programming paradigm, XP is overrated. But I think you are extremely unfair in your absolute judgment over it.
I have good experience using various parts of it. Pair programming one of them, though I didn't know what it was called, before XP labeled it.
Actually. A lot of the bad code you see around stems from 'lone ranger' coders, not realizing the fact that, programming like most other disciplines, is collaborate work.
Except for kitchen table projects most code is written with other people. Other programmers, designers, project managers, users ( damned be the last two) , and other stakeholders. XP addresses a lot of the problems you have when collaborating with these and so it can help you to get more time to code.

BTW: If it is the prospect of social contact that frightens you, just, develop a severe case of schizophrenia and pair up with the other you;-).

Re:Overrated (1)

utnapistim (931738) | about 8 years ago | (#16137040)

Others, such as pair programming just do not work in my opinion.

I haven't had long-term experience with pair programming, but from what I've tried it was cool. This involves a lot of issues to be agreed on beforehand, and respected, like the fact that "inactive guy" needs to actually be very active (follow the logic of the "hot seat", look for mistakes, watch the coding style and so on).

It also involves that the members of the pair are really equal (otherwise you have no pair there and the bennefits dissapear).

When writing code, it's good to have someone watching what you're doing, while you're doing it and being in tune with it (helping when you miss stuff, like "don't forget to increment the index" or "add a comment explaining that because it will look weird", or "we need to recalculate this here, because it might have changed").

I realize this can easily turn to nagging or become annoying, but with a bit of care in the team, you can avoid those situations (some people really are not fit for pair programming but that doesn't make the technique invalid).

When being the inactive coder, you can learn stuff, get a better overall perspective, relax more while working (actually both positions are more relaxing than solo-programming), and do pier review at the best possible moment (while the code is actually being written).

Re:Overrated (5, Interesting)

MobyDisk (75490) | about 8 years ago | (#16137071)

I found pair programming to be very efficient. But it depends on how you pair people.

(Summary of my best practices article [mobydisk.com] )

Junior developer alone: Can complete the project but with errors a senior developer could have fixed. Code reviews fix this, but are tedious.
Senior developer alone: Good code, but this tends to breed "cowboy coders" and doesn't pass on knowledge.
Senior + Junior: Highly effective, but only if the Junior developer is the one at the keyboard.

Other combinations can help, but aren't superb. I recommend pair programming (1) on tedious code, (2) to spread knowledge, and (3) when refactoring something crucial.

Re:Overrated (0)

Anonymous Coward | about 8 years ago | (#16137173)

Quite right... it's also a poor choice of name. Whenever anyone mentions extreme programming to me, I always imagine them in a bobblehat, skisuit, wearing mirrored sunglasses and with their mouth wide open; tongue stuck out and their index and little fingers extended. Wankers. I makes me want to punch them, the pepsi max twats... even if they are actually just a small fat geek wearing coke-bottle glasses.

Re:Overrated (1)

Eivind Eklund (5161) | about 8 years ago | (#16137202)

Some programmers are solo beasts. Some are not. And it really depend on who they are collaborating with, and the setting around it.

Have you noticed the "with snacks" meme that is going around everywhere in XP? "We don't know why, but this works much better when there are snack available in reach of the programmers." This one is true, in my experience. Pair programming work much better with it in place...

Eivind.

Re:Overrated (1)

Carl Rosenberger (449479) | about 8 years ago | (#16137210)

Whenever I see a comment that pair programming does not work I feel sad for the person that wrote it. Maybe you were very unlucky with the peer you were working with, maybe you were unlucky with the task that you were working on.

Without pairing my work would only be half as much fun and I would really miss the opportunity to learn from other people.

Some thoughts taken from a recent blog post [db4o.com] that I wrote:

- Pairing keeps you completely focussed on a single important task. This benefit alone at least doubles the productivity of every developer and makes pairing cheaper.
- Pairing produces better designs that last longer.
- Pairing prevents simple mistakes and saves you from loosing time in the debugger.
- Pairing fosters shared knowledge about the project that is being worked on. It makes it easier to exchange people between tasks.
- Pairing helps learning. People teach eachother programming techniques, patterns and ways of working with IDEs.
- Pairing helps raising the spirit of the team. It has worked extremely well to glue our team together, although we only see eachother in real life twice a year.
- Pairing activates the speech area of your brain and makes you more creative.
- Pairing is fun.

buzzwords (1)

arun_s (877518) | about 8 years ago | (#16136791)

agile approaches, agile software development in project management movement, open and honest communications
So what's this about, apart from the management-speak?
I feel like I read half dozen pages with barely any content.

Re:buzzwords (1)

aadvancedGIR (959466) | about 8 years ago | (#16136897)

agile software development is simply a way to say "code now, we'll get you the specs later"

Re:buzzwords (2, Insightful)

TechnoBunny (991156) | about 8 years ago | (#16136937)

But thats not necessarily a problem - how many projects are based around the same requirements as they were when the first line of code was written? Of course, in an ideal world they would be. But the world isnt ideal. Far better to start work accepting that the code you write may well be thrown away at some point, and continually refactoring to keep on track towards the changing target.

Re:buzzwords (1)

darkchubs (814225) | about 8 years ago | (#16136958)

web 2.0 user contributed content revolution started in 2005 with myspace Ajax Because DHTML was too hard to say if you were bound and gaged in the trunk of a mobster, and managed to get to a cell phone.

Re:buzzwords (4, Insightful)

Anml4ixoye (264762) | about 8 years ago | (#16136988)

I view XP as a methodology to solve a major problem I've seen in software - communication.

Why do we build software? It's to provide value for our customer, whether that customer be a marketing department, a gamer, or ourselves. And if we don't keep in touch with what it is that they want (recognizing that people generally don't know what they want until they see it), we probably won't provide the value we could.

To that end, XP encourages constant communication by using frequent releases of the stories (read: features) the customer thinks are most valuable. The customer gets a working version every week, or month, or 2 months, or whatever cycle seems to work for the team.

From the development side, XP encourages the code to always be potentially shippable by having a suite of Unit and Acceptance tests (the former written by the developer /before/ the code is written, the latter written by the customer(!)). We continually run them using a Continuous Integration server which monitors the code repository and checks out the latest version, notifying the team of any conflicts.

It also encourages things like Collective Ownership, where, in theory, any developer can sit down and work on any part of the system. This is achieved partly through the unit test suite, and partly through pair programming with frequent swapping (we swap pairs generally twice a day, in the morning and at lunch, but some teams do more, and some do less).

But, regardless of all the practices (and there's more than I'm listing above), the end goal is /not/ to be "XP", it's to deliver value to the customer. And if your current practices are doing that, then that's what is important.

As far as TDD, I have a series I recently did which shows how TDD works here (part 1) [cornetdesign.com] and here (part 2) [cornetdesign.com] .

Re:buzzwords (1)

Ignignot (782335) | about 8 years ago | (#16137132)

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?

Re:buzzwords (1)

ClosedSource (238333) | about 8 years ago | (#16137185)

As any old married couple can tell you, being in the same room doesn't guarantee communication.

Congratulations ! (0)

Anonymous Coward | about 8 years ago | (#16137003)

You just found out what the "extreme" in "extreme programming" refers to.

"XP makes improvement possible" (-1)

Anonymous Coward | about 8 years ago | (#16136800)

Noooooooooooooooooooooooooo!

(I have to eliminate repetition somehow, so I guess I'll do it like this)

Re:"XP makes improvement possible" (1)

arun_s (877518) | about 8 years ago | (#16136819)

*skims article*

XP blah blah trust blah improvement blah Embrace blah

*kicks in knee-jerk anti-M$ flame*

Re:"XP makes improvement possible" (0)

Anonymous Coward | about 8 years ago | (#16136976)

When are slashdotters going to figure out that eXtreme Programming (sometimes called XP) has nothing at all to do with Windows XP? They happen to share a two-letter abbreviation, but that's it.
XP != Windows.

Unfortunate name (1, Funny)

Timberwolf0122 (872207) | about 8 years ago | (#16136843)

Its principles of transparency, trust and accountability


I find this funny as the programming behind Windows XP relate to none of these.

XP = Extreme PR (1)

gjuk (940514) | about 8 years ago | (#16136848)

Thank goodness Slashdot's there to help publicise not only ground breaking new books, but even new editions. I really wouldn't want to miss the opportunity to discover why I need to buy book v2.0.
Does anyone remember when Slashdot wasn't quite so heavily infected by the insideous PR virus?

Re:XP = Extreme PR (1)

blowdart (31458) | about 8 years ago | (#16137099)

And what else would you expect from someone who writes a book on the topic, a neutral point of view where both good and bad points are discussed and taken on board? No, that would be too useful for a technical news site, instead lets recycle old PR puffery.

Laundry? (3, Funny)

LaughingCoder (914424) | about 8 years ago | (#16136860)

FTA:
I think that the first book was in reaction to a culture for programmers that was basically camping in their cubicles in Silicon Valley where people were spending their entire lives living out of cubicles with food brought in and laundry taken out.
There are places where they take out laundry? Real programmers don't change their clothes until the job's done!

Re:Laundry? (1)

chawly (750383) | about 8 years ago | (#16137015)

Showers ? With soap?

Why is it called "Extreme"? (4, Funny)

10Ghz (453478) | about 8 years ago | (#16136870)

To me, the word "extreme" sounds like they program in assembly 24x7 for one week straight, or they program with laptops, while running away from a pack of wolves or something. But apparently it's not like that. So what makes it so "extreme"? Did they come up with that name when they were discussing their interests with their jock-friends?

"Oh yeah, I'm in to pretty extreme things. Currently I'm doing base-jumping and ultimate-fighting. How about you?"
"Well.... uh.... I'm in to.... EXTREME programming"
"Whoa! Radical!"

Re:Why is it called "Extreme"? (1)

aadvancedGIR (959466) | about 8 years ago | (#16136924)

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.

Re:Why is it called "Extreme"? (4, Funny)

Anonymous Codger (96717) | about 8 years ago | (#16137011)

It's called Extreme because they take some basically good ideas and push them to such extremes as to be completely useless in the real world.

Re:Why is it called "Extreme"? (1)

kfg (145172) | about 8 years ago | (#16137012)

Buzzification. If it had been "invented" a bit earlier it would have been called "Turbo" programming.

KFG

One of the best quotes ever... (4, Insightful)

chuckplayer (994706) | about 8 years ago | (#16136898)

Kent Beck hits the proverbial nail on the head with this zinger (which I'm sure is certain to stir up quite a few):

"It's not all about programming. It's not all about programmers. Programmers aren't somehow special and to be protected and coddled. I used to say often that programmers were children. They liked not to be yelled at and to have more toys ... I think programmers are, or at least can be, adults and can and should, for the good of development and themselves, act that way."

The above quote sums up almost every problem that I have seen over the past 10 years with the various development shops I've been a part of.

Is he a manager ? (3, Insightful)

aepervius (535155) | about 8 years ago | (#16137148)

Because all the programmer I know around are quite adult, responsible, and do not care for the latest toy. But they do care that they are given enough time to implement features, taht the features are correctly documented, that the spec are there etc... And in the last 6 years I was there, those point were not met, and usually the manager were responsible for a reason or another, but never beared the responsability.

To sum up, to define the programmer as "child", is really disapparging, and far far away from reality of the average software developpement shop. Most are average guys which want to do a correct job, but are put in impossible situation by management.

No if the quote would be applied to manager "manager are like child, they like to play and win, but do not wish any responsasbility in tehir action".

Re:One of the best quotes ever... (1)

ClosedSource (238333) | about 8 years ago | (#16137206)

Since Ken Beck isn't really a programmer it isn't surprising.

Not Extreme (1)

pryonic (938155) | about 8 years ago | (#16136944)

If it doesn't involve fire or razorblades it's not extreme. I hate the way the word has lost it's meaning these days...

Buy this book so they can eat! (-1, Offtopic)

Anonymous Coward | about 8 years ago | (#16136949)

Kent-and-Cin-dy-wrote-a-book, doo-dah doo-dah...

Never... (1)

Thrip (994947) | about 8 years ago | (#16136953)

Xtreme Programming: Never have so many invested so much on a proposition backed by so little evidence.

Yeah? One word: (1)

dpiven (518007) | about 8 years ago | (#16137020)

IRAQ.

Re:Yeah? One word: (1)

Thrip (994947) | about 8 years ago | (#16137068)

I stand corrected.

Real Extreme Programming (5, Funny)

niceone (992278) | about 8 years ago | (#16136962)

IMO real extreme programming should involve at least 3 of the following:

  1. Only having 24 hours to deliver the code
  2. Failing would cause thousands of innocent people to die
  3. Getting your interface specs from a dieing man after being helicoptered across town
  4. Using emacs
  5. Failing code review results in you and/or your spouse being shot in the leg

Re:Real Extreme Programming (1)

raduf (307723) | about 8 years ago | (#16137240)

3. Getting your interface specs from a dieing man after being helicoptered across town

Omg! This one is scary!

This article is rubbish (1)

s31523 (926314) | about 8 years ago | (#16137021)

Although I am a proponent of some XP concepts and feel certain concepts can help with software quality and delivery time, this article does not highlight any of them. This article is nothing more than "blah blah blah, XP is great, now go and buy my book". How on earth did the editors let this one in.

Write the test first (1)

Rik Sweeney (471717) | about 8 years ago | (#16137023)

I don't understand this. You write the test before you write the code? This doesn't work in real life because, as every experienced coder will know, the goal posts get shifted at the last moment, usually a week before the product's supposed to go live.

Re:Write the test first (1)

s31523 (926314) | about 8 years ago | (#16137134)

Yes, one of the ideas is to drive the development of a product through tests that are written first. The one concept missing is that this can't be the only testing since theses tests are mostly low-level, i.e. at the module/class level.

Here is a real example. I work in aerospace, and my responsible area is navigation. We use INS's as the base latitude/longitude for position estimation. We have 3 of them, for redundancy purposes. We have a heirarchy of rules which decide which INS will drive the navigation solution. My spec tells me that the selected INS chosen goes 1, 3, 2 and that the criteria for selecting is not failed and not in align mode. So I write a test which allows me to create an API/class like, INS.getState(), INS.setState (state) and Nav.GetSelectedIRS. I stub these out, and use them in a test, say:
LeftINS : INS;
RightINS : INS;
CenterINS : INS;
SelectedINS: INS;

LeftINS.setState(Failed);
RightINS.setState(Navigating);
CenterINS.setState(Failed);

SelectedIRS = Nav.GetSelectedIRS();

if SelectedIRS != RightINS {
TestFailure ("Wrong INS Selected");
}
else
{
TestPassed;
}


Now, I make it so this test fails, and it is up to the developer to respond to this test by making it pass. We don't have daily software builds, we have daily software test runs. Intuitively, it seems like more work, but it really isn't; you just do work out of order and it seems like you are doing more of it, when you do less work because you find more problems early on in the cycle. The above example is simple, but it is one of the first tests. Later, you expand the test to integrate more API and or classes, say the classes that status the sensors and declare their state. There is some work in setting up an environment like this, but it is worth it. Plus, you know when you are "done"; when all the tests pass, you are done. The tests can be written with higher level classes and be more tightly coupled to specs or requirements, and if written right can take the place of requirements thus reducing the amount of muda [wikipedia.org] .

Re:Write the test first (1)

Tony Hoyle (11698) | about 8 years ago | (#16137141)

In my experience the goalposts move as you write the code... 'oh, that's possible? then can you also do this, and it would be nice if a widget popped up here, and...'

Writing the tests first means you're going to be forever updating them as the specs change.

Re:Write the test first (1)

TechnoBunny (991156) | about 8 years ago | (#16137178)

But if the requirements change, and you update your code, then you're going to have to test it anyway to ensure that it meets the updated requirements, so there's no extra overhead to rewrite the tests first.

Re:Write the test first (1)

Aladrin (926209) | about 8 years ago | (#16137222)

As opposed to writing them just after you code something, and the specs change anyhow? What's it matter if you code the test before or after the actual code, if the specs change -after- you've done both?

One big idea from test-first is to keep you coding things that actually matter, instead of adding stuff 'I'll need later' and then never do. There's also the obvious benefit of having tests to cover everything.

Re:Write the test first (1)

aurelianito (684162) | about 8 years ago | (#16137158)

Well, you write the test 15 minutes before the code. So the goal post is quite fixed.
And, because you go live every coupple of weeks, and you have all the tests written before, it's easier to change the code to acomodate to the new requirements. If a test that is not suposed to break breaks, you know that there is some problem with what you did. This safety net allows you to program faster and simpler.

Looks like Standard Concept..... however (1)

hcob$ (766699) | about 8 years ago | (#16137030)

It looks like it's had the curse of consultants beat it down with their theory and "improvements"

XP vs XO (1)

BlindRobin (768267) | about 8 years ago | (#16137031)

Personaly I miss the days of eXtreme Obfuscation, when multi-year projects, even entire careers, could be made of producing and deciphering intentionally and inadvertantly obfuscated code. Especially when you really had to dig through 4 foot high stacks of 14 7/8 x 11 green bar source listings and associated core dumps just to figure out that some asshole was relocating buffers on a vector just to fsck with the person coming along behind him.

Point out major successes (1)

Oligonicella (659917) | about 8 years ago | (#16137050)

Perhaps XP should point out a few outstanding successes instead of perpetual promising of improvement. So far, in my experience, the net result is pretty abysmal performance and several extreme failures.

Stop the X! (1)

GNUALMAFUERTE (697061) | about 8 years ago | (#16137083)

This eXtreme-whatever fashion really has to end. It's just the new buzzword, but it has been way to far this time. Everything from candy and books to programming and movies are X.

We don't need EXTREME things, why don't you try with creative, different, innovative things?
People lives such boring lifes, and they have been buying shit for so many years that all the usual lies used to sell are not longer valid, so we have to go the the limits, THIS time there really is something new!. Bullshit.

All this stuff is the Paulo Coelho of Programming. Bullshit literature for those not manly enough to just code C/C++/Perl/Python/PHP. This are real languages, and they have all we need. But we are in the reign of Coelho's bullshit books; and so, something being just good is not enough anymore. It has to be different to everything else in every way possible, it needs shinny mirrors all over it, and it needs to be easy, it must "change your life", and "take you to new levels".

I'm tired of this world, that's why i don't live in it.

Treat programmers like other professionals! (3, Insightful)

Rearden82 (923468) | about 8 years ago | (#16137151)

"It's not all about programming. It's not all about programmers. Programmers aren't somehow special and to be protected and coddled."

As a programmer, I agree 100%. I expect to work and be treated like any other professional.

NOT as a lab rat for "extreme programming" or whatever buzzword-laden feelgood bullshit management scheme comes along this week.

You wouldn't go to a painter and say "I want you to make me a painting. It doesn't matter what it consists of yet, we'll worry about that later. Just start out with a box or something and we'll meet every day and figure it out from there. And just to make damn sure you can't get anything done, I've hired another painter whose role is to sit around and annoy you." So why does that make sense for programmers?

mod parent up (1)

ameline (771895) | about 8 years ago | (#16137231)

That was the most sensible post I've seen here so far.

GUI prototyping tool (2, Funny)

pnone (1003781) | about 8 years ago | (#16137216)

There is also one good tool called Petra supporting extreme programming prototyping http://petra.cleverlance.com/ [cleverlance.com] We use it and love it.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>