Why Extreme Programming Fails | Hacker News Reader

Why Extreme Programming Fails

codewright.blogspot.com

14 pointskfrench58116 comments

The thing that makes me most wary about XP is its origins. They developed XP practices while working on the Chrysler Corporation Compensation System, which was eventually scrapped in an unfinished state after 5 years.

However, XP is touted to be a system of practices to enable people to get software created on time and under budget that is more adaptable. The skeptic in me just screams, "But your first big test case failed on all those accounts. How can you recommend these practices when, in practice, they didn't work?"

Also: The 48 Laws of Power read more like the 48 Laws of Douchebaggery.

I was under the impression that while C3 wasn't finished when the project was terminated it was used productively after only two years.

Also, it the project replaced one that had tried to make something work for even longer, without producing anything working at all.

Also, I remember it that Kent Beck thought the projects ending had nothing to do with the performance of it.

The success or failure of C3 is a contentious point. However, I'm also wary of the testimony from people who have a stake in XP being successful rather than C3 being successful.

http://c2.com/cgi/wiki?WasChryslerComprehensiveCompensationS...

http://calla.ics.uci.edu/histories/ccc/

Can anyone clearly explain how these "laws of power" prove the author's point regarding XP? I've read this twice now, and I still don't understand the connection.

It seems like French is saying that these laws explain why some people wouldn't want to pair with some other people. I don't think anyone practicing XP would dispute that some pairs just aren't meant to be. However, I don't see how that leads to a failure of XP in general.

There is no need to pair program all the time. Like many things in XP, adopting them all fully all the time is overkill. We don't do pure XP. We don't do pure Agile/Scrum. We do what works for our company and with our personalities and with our projects.

Pair programming works on our team very well in specific sets of circumstances (e.g. something has to be built by a certain deadline) and by combining forces (and sharing the pain) you improve your odds of getting it done and getting it done in a quality manner.

I hate the term "driving" as it applies to pair programming. "Can I drive now?". Argh.

Yet another oversimplification. The 48 Laws of Power are certainly present in everyone's behavior, but it's a bit of a stretch to label them as the sole culprit for XP's failures.

Where is the claim that the 48 Laws are the sole culprit?

This xp post isn't that interesting, but the laws of power that it links to are http://www2.tech.purdue.edu/cgt/courses/cgt411/covey/48_laws...

Linkbait-ish title. It's more like: "Why Extreme Programming doesn't take hold."

XP and SCRUM can increase my productivity up to 300%. But, after 5 years of successful XP and SCRUM practice, I burned out. I just cannot think about work. Long vacations helps me a lot, but for short period of time - 1 month vacation restore my productivity for about 6 months only.

How to classify that? As success or as failure?

If it increases your productivity up to 300%, that means that you can work for 5 months, then take a month off. You will still get ~30 months worth of work done in a year. So thats a huge success.

You are right in general case. In my case, I was responsible for few large subsystems (Linux and related stuff, automated testing and continuous building, packaging, deployment, automating of common tasks, configuring, support and troubleshooting, training, documentation, reviewing, enforcing best practices, developing of development standards, predicting future problems, etc.). I just cannot leave that project for long period of time, because large amounts of tickets must pass through me in some way (investigation, suggestion, implementation, reviewing/fixing, approving).

I solved problem by training team, which replaces me. Then I leaved my work (IMHO, crisis is best time for that). Team works slower than me. Their solutions are not so good, because nobody has picture of whole project in his head. However, they can continue to work, while I cannot. As I can see, this scenario is typical.

IMHO, problem with XP and SCRUM that they producing too much load on the few competent persons. Overall result is better than with traditional methods, but competent person burns much faster, because they contribute more than others.

It is hidden magic beyond the process - XP and SCRUM just delivers task to competent person much faster than any other process. The drawback is that there no reason to grow for other developers, thus load on competent persons tend to increase over time. Pair programming and peer reviewing helps when people are roughly equal, but that is rare.

If we try to model situation, then we will see few major stages in evolution of project and/or group:

  * fast growing of project and/or group until physical limit of few key people will be hit;
  * degradation of group, because key people leave project, until there no overloaded people;
  * stagnation.

PS. I spent last few months to improve me in sport-dancing. I meet new very funny girl. I plan to work next 2 months as instructor for wind-surfing at Black Sea (Eastern Europe). I hope, it will help.

Then you are working too much. One of the tenants is "sustainable pace". Are you working more than 35-40 hours a week?

Tenets.

whoops, i selected the wrong one after i misspelled it as tenats. Thanks.

Extreme Programming works well for debugging code (not development)

Reply on news.ycombinator.com