In fact, you are quite wrong. XP was developed for the smalltalk system, which is more OO than C++ or any other language out there. Refactoring is not negating OO, it is simply saying "don't be so freakin' chicken to change your code to make it MORE oo and thus more re-usable".
Having practiced XP, it is similar to most methodologies in relation to the project triangle and other high-level management approaches. Its implementation, however, is where it significantly diverges. Anyone who throws up their arms and runs away at the ideas is simply adverse to change. Kent has some intriguing ideas that we have successfully implemented and a few new ideas on arbitrary approaches that I've always had problems with (i.e. one person estimating other peoples time, redefinition of the users requirements). The reviewer glosses over numerous key features to XP, such as story-writing, prototyping, and most importantly, pair programming, which is the key to XP. Pair programming is a cultural shift and is difficult to introduce simply because everyone wants their own "space". What you find; however, is with the proper environment, pair programming is quite natural and each of us has experienced it successfully in one way or another. You simply provide the developer with a place for them to go to to make their private calls or spend some time contemplating. Finally, XP only works in some environments. It's approach to modelling and testing doesn't work very well with UI-heavy products. You can only achieve automated testing in approx. 65 to 70% of the UI system (assuming a proper 3-tiered system and that the model represents the data and is not integrated with the UI) and ultimately have to resort to manually testing the GUI.
Slashdot Mirror
In fact, you are quite wrong. XP was developed for the smalltalk system, which is more OO than C++ or any other language out there. Refactoring is not negating OO, it is simply saying "don't be so freakin' chicken to change your code to make it MORE oo and thus more re-usable".
Having practiced XP, it is similar to most methodologies in relation to the project triangle and other high-level management approaches. Its implementation, however, is where it significantly diverges. Anyone who throws up their arms and runs away at the ideas is simply adverse to change. Kent has some intriguing ideas that we have successfully implemented and a few new ideas on arbitrary approaches that I've always had problems with (i.e. one person estimating other peoples time, redefinition of the users requirements). The reviewer glosses over numerous key features to XP, such as story-writing, prototyping, and most importantly, pair programming, which is the key to XP. Pair programming is a cultural shift and is difficult to introduce simply because everyone wants their own "space". What you find; however, is with the proper environment, pair programming is quite natural and each of us has experienced it successfully in one way or another. You simply provide the developer with a place for them to go to to make their private calls or spend some time contemplating. Finally, XP only works in some environments. It's approach to modelling and testing doesn't work very well with UI-heavy products. You can only achieve automated testing in approx. 65 to 70% of the UI system (assuming a proper 3-tiered system and that the model represents the data and is not integrated with the UI) and ultimately have to resort to manually testing the GUI.