• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Xtreme Programming!!?

Queasy

Moderator<br>Console Gaming
You can tell it's cool by the 'X'

Sounds interesting yet counter-intuitive at the same time:

[/i]When Kevin Yu went to work for Hewlett-Packard in December 1999, he was a prematurely jaded 25-year-old programmer who had already lived through layoffs at Compaq and done a stint writing code at Digital Equipment Corp. Like most programmers he was withdrawn. He followed orders obediently. He felt removed. He worked alone.

Yu still codes at HP, but these days he's gregarious, passionate, and eager to solve problems of every kind. His attitude adjustment is the result of a new approach to writing software that's transformed practically every aspect of his job. The biggest change: Each afternoon, he pulls up a chair beside a fellow programmer, and the two of them share a single workstation - one monitor, one desk, one keyboard. It's common to find him in HP's Seattle offices shoulder to shoulder with teammate Asim Jalis, who stares into the screen as Yu "drives," both of them pondering aloud whether a new idea might work. Later, Jalis types as Yu watches, exclaiming periodically, "I get it!" when the spray of code makes sense. Sometimes one partner works the mouse while the other uses the keyboard, like a married couple finishing each other's sentences.

Yu is among thousands of coders who've discovered extreme programming, a method of software development that emphasizes constant feedback. Traditional coding devotes a huge amount of time to up-front planning, then demands rigid adherence to that plan. XP is different. Programmers spend relatively little time planning and instead dive into the writing, making course corrections as needed and allowing better ideas to emerge after snippets of code are tested and assessed. The result is a speedy loop: plan, code, test, release, plan, code, test. [/i]
 
Heh, I remember first hearing about xtreme programming back in high school some 5 years ago and I remember thinking, "WTF is the point of 2 people at one keyboard." 😛
 
xtreme programming, imo, sounds like a terrible concept. It's infinitely easier to plan something than write code first and ask questions later.
 
I think this makes sense. I've never done this professionally before. But, it's not uncommon for a buddy and I to do this while hammering out a project of our own or tweaking someone else's code.
 
I've never tried it. Some people like it but I am not sure if I would. i think it would only work if both people were very close to each other's capabilities. Otherwise it would not be an even split. I spend certainly less time coding than thinking, so the one workstation isn't the problem. However, a lot of things I do I have planned in my head and sometimes work through them in my head silently as a type and i don't see how I could apply that to xtreme.
 
i think it would only work if both people were very close to each other's capabilities.

Yeah, thats one of the things I remember being emphasized. It doesn't work when the two programmers are on different skill levels.

However, a lot of things I do I have planned in my head and sometimes work through them in my head silently as a type and i don't see how I could apply that to xtreme.

You wouldn't really. You explain it to your partner and hope he understands.....
 
Actually, one of the fundamental cornerstones of XP is writing a complete battery of battery/suite of TESTS prior to doing any coding. This way, the developers (remember two with pair programming) understand exactly what the code is supposed to do, by virtue of the tests that have already been written.

This is how you can make progress without the planning and documentation that is typically seen in waterfall process models. Having said that, what I most often see is a hybrid of "XP" where coders don't write tests and don't work in pairs, planning isn't done and documentation isn't complete. So, you end up with a huge mess of unmaintainable spaghetti code and a project in chaos that is supposed to be going through the V&V phase.

Originally posted by: yoda291
xtreme programming, imo, sounds like a terrible concept. It's infinitely easier to plan something than write code first and ask questions later.
 
We did this as an experiment in my first year of my CS degree.

Basically, my class was a guinea pig for some older grad students who were testing the philosophy of Xtreme Programming.

Xtreme programming SUCKS. With some good planning and modularization of the code, two people will be far more efficient programming separately than together.

-Ankur
 
Originally posted by: anxman69
Xtreme programming SUCKS. With some good planning and modularization of the code, two people will be far more efficient programming separately than together.
I can see it helping two weak junior programmers, so that together they have one complete brain 😉

For someone experienced, this would be boring and slow torture, sitting and watching someone else key in a solution instead of just doing the work yourself.

Desk checks / code reviews of other peoples' code makes good sense. Downin' a Dew and doin' the Xtreeeme!!! pr0gr4mM1ng!! is a gimmick to get tenure and make money froml books, seminars, and consulting.
 
It seems there are some pretty heated opinions of XP; however, it seems only one person actually knows what XP is even about. How can someone say something sucks and not even get the name right? That's like saying "eXtensible Markup Language" sucks. If you haven't educated yourself enough to even know that it's *extreme programming* and not xtreme programming, then really any opinion seems moot. There is a lot more to XP than pair programming.

Being a proponent of agile methodologies in general, I can confirm that XP can, and indeed does, work. Many of the major tenets of XP (TFD being probably the most pervasive--look at tools like JUnit/NUnit, etc.) are very well accepted in the developer community; granted, not always under the guise of XP. There are some XP-purists who feel that if you don't employ all tenets of XP that you're not doing XP, but not many argue that at least some of the ideas are indeed very valuable.

So seriously, at least read Extreme Programming Explained, then Agile Software Development, then Agile Software Development before passing such a superficial opinion.
 
Originally posted by: DaveSimmons
Originally posted by: anxman69
Xtreme programming SUCKS. With some good planning and modularization of the code, two people will be far more efficient programming separately than together.
I can see it helping two weak junior programmers, so that together they have one complete brain 😉

For someone experienced, this would be boring and slow torture, sitting and watching someone else key in a solution instead of just doing the work yourself.

Desk checks / code reviews of other peoples' code makes good sense. Downin' a Dew and doin' the Xtreeeme!!! pr0gr4mM1ng!! is a gimmick to get tenure and make money froml books, seminars, and consulting.

Bah. Why do people always refer to pair programming when admonishing XP? True, pair programming is not always a feasible idea, but it does work! Some of the more volatile projects have required two programmers per workstation for decades. I personally don't pair program, but that doesn't mean XP is a failure. Just like RUP/MSF/etc. are not palatable for certain environments, nor is XP. Unfortunately there will never be 1 process that accommodates all projects, and it's up to the experienced to pick and choose the tenets of each that best fits the project at hand.

As always, choose the right tool for the job.
 
So ghey. We have a couple of people at work into that. Last thing I want to do is sit next to a grubby coder all day, yuck.
 
Originally posted by: dwell
So ghey. We have a couple of people at work into that. Last thing I want to do is sit next to a grubby coder all day, yuck.

Again, there is more to XP than pair programming. The idea of pair programming is NOT new, it was merely adopted under XP.
 
my lab partner and i did this for my lab this summer. it was pretty fun. we're good friends anyway, so that kinda helped. for our lab, we got only one terminal to work with anyway, so this is what we had to do. he'd be doing something and i'd propose changes to his idea and we'd fine tune it immediately, etc. i thought it was pretty efficient.
 
Everyone here is an uber programmer, why would they need to work with someone else?

rolleye.gif
 
I love this idea! I never liked the lengthy and boring planning phase of programming, and always wanted to dive right into the coding phase. Perhaps if this concept had been a widely-accepted practice when I was programming I might not have dropped out of college and enrolled in a different school for an entirely different field. Oh well, now I know if what I'm doing now doesn't work out (aviation) I might be interested in programming once again.
Thanks for posting this Queasy.
 
Originally posted by: Flyermax2k3
I love this idea! I never liked the lengthy and boring planning phase of programming, and always wanted to dive right into the coding phase.

Don't confuse an agile methodology such as XP with cowboy coding (i.e. jumping right into coding sans any forethought). You *do* plan with XP, just at a much more granular scale. If you're really interested, the books I recommended above would be a good place to start.
 
They've been testing this concept out in various groups at my workplace. Mostly I only hear complaints about it. Its especially bad when you throw deadlines into it. I think its a good idea but its not quite ready for use in most businesses. Right now it looks good on paper because it churns out results rather quickly. Unfortunately those results are usually not as good as a normally engineered product.

I also think stories like this one are ridiculous. No one is gonna suddenly have a good life because they started extreme programming. Its not the greatest thing since sliced bread. It just can be more suitable for small projects at times.
 
i hate when people promote these programming methodologies, half of the stuff is comon sense, half of it is just writing it down as a formal process.
 
Originally posted by: DanTMWTMP
my cs prof. during first yr advocated a similar practice...dr, savitch was cooool.....

you goto UCSD? I had Kube, hes cool too, scarey mofo but a cool guy.
 
Originally posted by: Ameesh
i hate when people promote these programming methodologies, half of the stuff is comon sense, half of it is just writing it down as a formal process.

As with most things, the amalgamation of ideas under a common vernacular is the main benefit. Design patterns in software were employed long before GoF, but the book unified the vernacular. The same goes for methodologies.
 
Originally posted by: Descartes
Originally posted by: Ameesh
i hate when people promote these programming methodologies, half of the stuff is comon sense, half of it is just writing it down as a formal process.

As with most things, the amalgamation of ideas under a common vernacular is the main benefit. Design patterns in software were employed long before GoF, but the book unified the vernacular. The same goes for methodologies.

IMO these methodolgies arent as big of a contribution as the gang of four made.
 
Back
Top