From WikiWorld

Jump to: navigation, search

"Extreme Programming (XP) was created in response to problem domains whose requirements change. Your customers may not have a firm idea of what the system should do. You may have a system whose functionality is expected to change every few months. In many software environments dynamically changing requirements is the only constant. This is when XP will succeed while other methodologies do not."

The extreme programming methodology includes "rapid incremental prototyping" with deliverables approximately every two weeks and feed back from the users so that you can easily gauge the value being created and be sure we are developing the system you want.


Discussion: I've found Extreme Programming laughable. Some how, the tragedy of the programming profession/field returning to the state I was first introduced to it (back in 1977), just strikes my dark, twisted humor. About the only thing differences between then and this are: -customers included a bit more often, -having the co-pilot constantly, rather then as a matter of anytime you needed to think outside your head or collaborating on code seams.


I've used many different methodologies since 1967. Extreme programing is the best I've seen and I think it will work. I advocate it, but admit my use of it is token. What would you suggest?

  • the buddy system means more than one person share responsibility for and can maintain the code, not that you have two people sitting together at every computer. We all get stupid at times, a code reveiw ealy can save a lot of wasted effort and help insure we are solving the right problem in a reasonable way.
  • Extreme programming in essence is incremental rapid prototyping using a light weight methodology that does not impeed the process.

-- JimScarver

And what you are talking about sounds to me exactly what I was introduced to, back in 77. I just have to wonder what happened between 1977 and, oh 3-5 years ago to make 'Extreme Programming' need to be evangelized and spread to the mushroom masses. What happened to the standard software practices in between? I must have missed that, as very few places I worked in between didn't do exactly that.

Rapid prototyping? That's a business buzz word that should have been still born (same as pro-active and paradigm shifting/changing). People need to be able to see what is being worked on, at all stages. It's just how software is. A small item/problem is easy to design and not need to be seen, algorithmically speaking, but the interface needs to be used to find out if it is HumanEngineered well. A large item or related/interacting group of problems addressed by an Application/System, however, has to be 'Baby Stepped' along (Which is what RapidPrototype is... the original C design methodology I was introduced to). Part of the reason for that is Moving Requirements (Project requirements always change when not done in 'almost instantaneous' time). Part of that will be Refined Problem Domain (Gaining a better understanding of what is happening, what your True/Implied Requirements are, and gaining improved communications between Customer/User and Designers/Implementors).

Maybe the problem was, that way of working and its methodology was known so well, it went unspoken. I was certainly never taught anything other then 'More then a screenful is too much' (a C Coding style/ethos of the time). I absorded it by sheer immersion (monkey see, monkey do). Humm... when things go unspoken, they can get lost and forgotten I suppose.

Or maybe just much Empire building and Egotism happened throughout the industry. Humm... Well, regardless, my dark, twisted sense of humor finds it great comedy that the industry is trying to be so 'Cool' in it's methodolgy (and use those Marketing words and tricks as well, sheesh====) and rediscovering what is old, tried, true, proven, and the first 'Team Work'/Coordination model I was introduced to. ====

So... we are fighting the Prima Model and Empire Building by using 'Extreme Programming'? Trying to cover 'a bus ran over our coder that knows that'? Just what is the standard then, that industry has to be taught what was standard practice and knowledge?


In 77 most companies were still doing 3 months of planning, 3 months of coding, and three months of testing, delivering software only to find out that the system doesn't meet current requirements because a lot can change in nine months.

I just consider extreme programming to be an umbrella for good practice today for facilitating successfull collaborative software design and development efforts. Everybody doing their own thing does not work in a collaborative development. Each group can choose what methodology they want to use but if it isnt well defined it wont be used. We pick and choose the extreeme programming practices we want to use but we would be better off using more of them, I am sure. Individuals may diverge from the methodology but the chosen methodology still provides the overall project structure.

I don't care what it is called, but it must be well defined.

Y'all missed some of the practices of XP, and so end up with sort-of a parody of hacking. XP is actually high-discipline. Among the practices that make it high-discipline are test-first development and constant refactoring (the Once and Only Once rule). Some people who advocate so-called Agile Development are skeptical about XP because of the high discipline, that is, people tend not to be highly disciplined.

I suspect the amount of hype in the name and movement may bother StarPilot, too. I agree, but I guess that's how movements happen. --- BobHaugen

Extreme Programming seemed fairly revolutionary to me. Perhaps it is not anymore. But is does employ sound principles to continuous improvement of the software development process. Most consider it to be an Agile methodology providing an alternative to documentation driven, heavyweight software development processes.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

See http://agilemanifesto.org/principles.html

In addition to [[|http://www.pragmaticprogrammer.com extreme programming||http://www.extremeprogramming.org]], Agile development flavors include |http://www.controlchaos.com, |http://www.dsdm.org, |http://www.adaptivesd.com/pubs.html, |http://crystalmethodologies.org, |http://thecoadletter.com/download/fddguide and Pragmatic Programming.

I like the extreme connotation, but that's my nature, program with gusto or why bother :) - JimScarver

See ExtremeCollaboration, CriticalChainProjectManagement

Personal tools