XP Refactored Review
|
- Book: Extreme Programming Refactored: The Case Against XP
- Authors: Matt Stephens, Doug Rosenberg
- Publisher: Apress
- Reviewer: SunithaDangeti
Having practiced XP, I particularly like two chapters in this book, one on XP in a nuthouse which is a good read for someone who is new to XP to get a quick understanding of the XP concept and the next one is the chapter on XP refactored in which the authors point out good features of XP along with their own best practices added and ideas that may make XP better.
This book is an extreme view of Extreme programming. The authors have criticized almost every aspect of Extreme programming. Any developer thinking of following the methodology would be discouraged to do so if they came across this book first.
They take a very rigid stand on refactoring, picturing as if XP programmers are in a constant refactoring frenzy for no good reason. Lack of initial design has been pointed out as being responsible for lot of rework. Release early, release often concept has been shown to increase the developers concern of whether it will integrate into the system and satisfy all the tests or not.
They point out that XP is not scalable and is only suitable for small projects. Though most of the XP projects are small, I know the above statement is not entirely true as I heard a success story of a big project which was migrating and had a strict production deadline to meet which it did.
The authors picked examples from instances where the coders did not take care of situations. For example, they comment on unit tests saying that unit tests are stand alone in XP and often left databases dirty. The developer in that instance may not have had roll back statements in the test which is why the database was left dirty and hence it is not a flaw with XP methodology but a flaw with the way it was implemented.
By the end of the book, the authors refactor XP and delineate the pros and cons of each XP component in which they mention the following points:
- Pair programming should not be constant or mandatory
- Programmers should design
- Programmers should write their own tests
- Instead of continuous design, we should follow frequent design
- 40 hr weeks are not feasible as sometimes developers have to work overtime to meet deadlines
- Coding, testing, listening and designing of XP are worth salvaging
- Iterations should be one month long
- Test first design should complement the design but should not drive it
- Use a combination of requirements and use cases instead of user stories
- Project velocity should be measured in terms of formal requirements completed per iteration rather than user stories per iteration
Overall, I thought it was a fairly good though quick read for me
XPSD book reviews are written by XPSD members. If you want to receive a book - free - for review, just let us know!