Extreme Programming? (XP)
Author
This may be a really dumb question, considering I've been into programming for almost a decade, but I've noticed a few people on the forum refer to "Extreme Programming". Could someone please tell me what this is exactly. Thanks!
Extreme Programming defined
The basic gist of it is, the requirements analysis stage is completed with the client whislt building the prototype of the system. It's the next generation of RAD.
The basic gist of it is, the requirements analysis stage is completed with the client whislt building the prototype of the system. It's the next generation of RAD.
Author
So in other words, you start building it before you figure out what you want built, then adjust it as you go?
I think in practice, XP is a sort of formalization of good old "garage band" programming. Small teams of smart developers working on short-duration milestones to incrementally move the product forward. Involving the client in all the increments helps manage expectations.
I believe another tenant of XP is "team" programming, where at least two programmers are on every task. This has tons of benefits, although isn't always practical.
I believe another tenant of XP is "team" programming, where at least two programmers are on every task. This has tons of benefits, although isn't always practical.
Quote:Original post by Alex
So in other words, you start building it before you figure out what you want built, then adjust it as you go?
Basically, yes. Personally I feel that XP leads to lazy designing. I've worked on some truly massive systems, and it is very rare that you cannot plan out and design the code from the beginning to totally eliminate the need for refactoring. Certainly some unexpected things will come up, and designs will almost always change a bit during the development process - but nothing on the scale of what XP advocates would advise.
XTreme Programming is not ment to be used with massive projects :) It is made to work only with small to middle sized projects with fairly small teams.
In case you design a massive system you indeed need to spend more time on the design. Otherwise things can go really wrong.
In case you design a massive system you indeed need to spend more time on the design. Otherwise things can go really wrong.
Sorry, I didn't really make that clear. What I meant was that even in incredibly complex systems it is possible to design the whole system and never need major changes to the design. By extension it should be much more possible to design simple projects in such a way that refactoring is never needed. I've long since learned to thoroughly design my projects before I begin coding, and no matter how big the project is, the time saved by not redesigning and rewriting the code 10 times is very valuable. A lot of XP proponents like to try to cast a bad light on sticking with a proven design (for example, the site linked above blatantly accuses developers who don't refactor of being afraid of change, or too self-centered to admit their designs need change). This kind of propoganda is a major red flag to me. If you did your design work properly, there should never be a need to change it. Encouraging refactoring ("whenever and wherever possible") has always struck me as a lazy and irresponsible approach to design.
Anyways, to get a fair view of things, I'd advise reading up a bit on XP and then checking out this book. There are far better approaches to programming than XP.
Anyways, to get a fair view of things, I'd advise reading up a bit on XP and then checking out this book. There are far better approaches to programming than XP.
One of the main things what XP tries to achief is quick results and being dynamic as in allowing easy changes in application requirements. In some ways it is kindof like RAD.
With XP you start with a global design, and don't really go into details. Then you start implementing it, and you will find some things that can be done better or things you didn't think of yet while doing the initial design. Then you adjust the design again to match your code, and do that in iterations.
This is also why it won't work in huge complex systems, probably like 3D engines. Well, it will work, but like you said, you will really spend lots of time of refactoring and rewriting and adjusting the code (and design).
But XP is also not good in those situations.
It is good when you have a small project, and a client that likes to see quick results. You can show them progress very quickly and they can give feedback like: "it would be better if it woudl work that way". When you have totally made a fixed design upfront, you will have possibly done a lot of work for nothing. With XP you don't loose much time here.
So for small projects XP can be really good. However, I'm not a huge fan myself of using a methodology exactly the way it is described. You can adjust it to your own needs.
With XP you start with a global design, and don't really go into details. Then you start implementing it, and you will find some things that can be done better or things you didn't think of yet while doing the initial design. Then you adjust the design again to match your code, and do that in iterations.
This is also why it won't work in huge complex systems, probably like 3D engines. Well, it will work, but like you said, you will really spend lots of time of refactoring and rewriting and adjusting the code (and design).
But XP is also not good in those situations.
It is good when you have a small project, and a client that likes to see quick results. You can show them progress very quickly and they can give feedback like: "it would be better if it woudl work that way". When you have totally made a fixed design upfront, you will have possibly done a lot of work for nothing. With XP you don't loose much time here.
So for small projects XP can be really good. However, I'm not a huge fan myself of using a methodology exactly the way it is described. You can adjust it to your own needs.
Adjusting XP's methodology can be deadly. This should explain more about what I mean here.
There is far too much potential for things to go horribly, terribly wrong with XP. I've never had any trouble getting results for my clients, and I've worked with some incredibly anal people in my time. Of course I'd also say that the customer-involvement aspect of XP is another one of its major flaws; customers do not know how to design good software in 99.9% of all cases, and involving them directly in the development phase is a good way to get derailed and led down some ugly paths.
XP may or may not work in certain scenarios, but my question is, why risk it? I'd be willing to bet that there is no real gain from using XP in terms of time or money, and that leaves you with nothing but a gaint mass of potential problems. Better safe than sorry.
There is far too much potential for things to go horribly, terribly wrong with XP. I've never had any trouble getting results for my clients, and I've worked with some incredibly anal people in my time. Of course I'd also say that the customer-involvement aspect of XP is another one of its major flaws; customers do not know how to design good software in 99.9% of all cases, and involving them directly in the development phase is a good way to get derailed and led down some ugly paths.
XP may or may not work in certain scenarios, but my question is, why risk it? I'd be willing to bet that there is no real gain from using XP in terms of time or money, and that leaves you with nothing but a gaint mass of potential problems. Better safe than sorry.
Quote:Original post by ApochPiQ
Adjusting XP's methodology can be deadly. This should explain more about what I mean here.
See (XP guy) Ron Jeffries' review of their book
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
