[m-e-g-a-z]

I recently came across the Extreme Programming methodology and wanted to know when and where this is most suited in the industry. What makes extreme programming more suitable or not compared to other software development methodologies?

[NeoTifa]

Extreme programming? Is there some type of danger involved? Like, there's a car battery hooked to your nipples and every time you get a bug in your program it sends a jolt of electricity, while you are dangling over a water pit with frickin sharks with frickin lazer beams attached to their frickin foreheads swimming around? Omg.... That's awesome.

This post has been edited by NeoTifa: 22 July 2010 - 05:51 AM

[SpeedisaVirus]

I personally have little to no industry experience but did some research on it in applied settings in the past. What I read mostly was that it didn't scale well to very large projects/organizations. That is if it's applied naively I suppose. It seems like it would be possible to intuitively segment even the largest project. I read about that too but don't recall the details.

Most of this stuff was written on experience but I wouldn't mind hearing what folks here have to say...can't believe everything you read after all.

[Jstall]

I've heard of a couple of places around here actually experimenting with this but have not heard how well it has worked out for them. I would guess that because it emphasizes programming in pairs a major factor would be how well the two programmers styles compliment each other and how they are able to get along in a duo type dynamic, which would be significantly different than working on a team.

In school I worked on a fairly large project with someone who's style and abilities complemented mine very well. We were able to play to our strengths with one of us working on parts of the project where the other was weaker. It worked out really well.

On a side note NeoTifa's description could also be incorporated, although I suggest that in order to be truly extreme it should also involve explosions and the project lead should periodically burst into the room playing an electric guitar to keep the mood consistent.


Jstall

[Martyr2]

1. The practice requires programmers to listen to business consumers (non-techies) to understand the problem... lots of programmers do this badly.
2. It allows the flexibility to start up a feature that is needed right then and not planned before the project. "Wouldn't it be cool if it did this?" whether or not it really is needed... programmers do this well
3. It requires lots of GOOD communication between everyone involved...programmers are not usually very social.
4. Requires the customer to be always available for consultation... haha right... business people at the developers beck and call. Not going to happen.
5. It often involves pair programming... half of all programmers hate this idea... and they are usually the ones watching the other 50% coding.


Are there any really doubting why this isn't in the main stream of the industry? In theory the practice is sound if you have someone who can truly manage the project and also have a customer who knows what they are doing and what they need. Since this rarely happens, this is why you don't see this much out there and almost never for large development firms.

[macosxnerd101]

Hahaha. This sounds exactly like my nonprofit wen project. My clients were available 24/7, and expected the same from me/us and the Center Chairman.

1. We did this fine.
2. This pretty much sums up my project, as this point was ever so persistent like 20+ times/day.
3. Over-communication was actually a problem, as I spent more than an hour a day responding to and forwarding emails.
4. Not a problem.

If you want to use this process in the real world, be prepared to have:
-A team of HR people willing to deal with clients 24/7
-A team of social Developer-type (PM, Lead developer, etc.) willing to talk with the clients
-A team of skilled and efficient developers
-A restraining order against your clients
-High-profile and high-dollar projects
-The desire to sell your soul

Trust me, don't go for this process. You will be making your life hell.

[m-e-g-a-z]

Martyr2, on 22 July 2010 - 03:45 PM, said:

5. It often involves pair programming... half of all programmers hate this idea... and they are usually the ones watching the other 50% coding.

It would be more efficient if each programmer worked on a part of the system. My personal opinion - I hate pair programming.

[raziel_]

in my firm it`s the religion of my boss. i find this extremely bad method no to mention that documentation for the program is very poor. it is all ok till we sell the program to new customer. no to mention how the programmer hate to contact with other ppl

This post has been edited by NoBrain: 22 July 2010 - 10:10 AM

[taylorc8]

What's this? pair programming.. I call neo.

[Krishs]

Martyr2, on 22 July 2010 - 09:15 PM, said:

1. The practice requires programmers to listen to business consumers (non-techies) to understand the problem... lots of programmers do this badly.
2. It allows the flexibility to start up a feature that is needed right then and not planned before the project. "Wouldn't it be cool if it did this?" whether or not it really is needed... programmers do this well
3. It requires lots of GOOD communication between everyone involved...programmers are not usually very social.
4. Requires the customer to be always available for consultation... haha right... business people at the developers beck and call. Not going to happen.

customer oriented approach for programming ... that the key point of extreme programming for improving corporate and enterprise world s/w.

[NeoTifa]

taylorc8, on 23 July 2010 - 01:19 AM, said:

What's this? pair programming.. I call neo.

Idk, I'm pretty bad at the programming thing.

[tlhIn`toq]

What am I missing here?

• Listen to the customer...
  
• Have the coder actually understand what the customer wants...
  
• Plan ahead...
  
• Accept at the start there will be features to be added later...
  
• Have the customer use the program, then give feedback as to how to improve it...

Is this really what is being defined as "extreme programming?" Those are the founding principals for our company. And what I would consider the most basic of requirements to develop software.

I must have missed something extremely vital for the "extreme" part.

[NeoTifa]

tlhIn, on 23 July 2010 - 09:34 AM, said:

...I must have missed something extremely vital for the "extreme" part.

NeoTifa, on 22 July 2010 - 06:50 AM, said:

Extreme programming? Is there some type of danger involved? Like, there's a car battery hooked to your nipples and every time you get a bug in your program it sends a jolt of electricity, while you are dangling over a water pit with frickin sharks with frickin lazer beams attached to their frickin foreheads swimming around? Omg.... That's awesome.

[PsychoCoder]

taylorc8, on 22 July 2010 - 10:19 PM, said:

What's this? pair programming.. I call neo.

Pair Programming

[NeoTifa]

Our programming competitions are set up this way. In fact, I got so frustrated with the "driver", I smacked him and did the whole thing myself. I got 20th out of 88 I think.