Book Review: Extreme Programming Installed
To finally catch up with all my book reviews, I have also completed the “Extreme Programming Installed
The book was decently well written, and while it was penned by four authors the flow seemed to be consistent. Some the chapter content seemed to jump ahead and back again, with multiple references to other sections. While somewhat helpful in the later chapters, it was very annoying the earlier ones when it talked about concepts not yet introduced, or left you hanging on what they meant.
I have not been on a XP project yet, so I really can’t say much on the methodology itself. I’ve talked with people who have used it to the hilt and love it. Here is just my take on a few of the ideas it brings up:
-
The idea of paired programming is very interesting to me. I know that when I'm stuck on something having another pair of eyes is a great thing. Usually the problem is just something I've overlooked. Even with all the benefits that they list as to why paired programming is such a great thing, I wonder how many customers are interested in paying for two consultants to work on the same bit of code (no flames on that please, I agree whole heartedly on the concept, but am not sure about how to sell it once price is an issue) . The concept of estimating in smaller iterations is also I think I would like. The breaking down of requirements into stories makes sense. The estimation sections I thought were pretty good. I my mind I already to a lot of the breaking down of requirements . Allowing the customer to drive what stories are written for an iteration and to move the project along by having multiple small iterations is also very appealing. The problem is that some of the clients I've been to would simply not buy into this. They had to have everything done or "we can't do our work without it", or "the product will simply be no good to us without all of this in there in the first go around". Of course, you always find something is dropped and other added as things go along. Again, selling this to the customer will be interesting to say the least. Especially if they are not used to this method . They promote the idea of only writing what you need to write for the moment. Not what you may need in the future. While I somewhat agree with this, I've seen a LOT of rework for a system because known future requirements were not taken into account. While I don't think that you should spend gobs of time working with "what may come", I think an eye to it is a good thing. If you can spend an extra 10 hours now to design something that will handle the case in the future instead of 100 hours of rework later, then all the better. But I would say this needs to be finely judged for each instance . Because they advocate just writing what you need and refactoring as you go they also state that laying out a formal structure in your source control early on isn't recommended. If they've ever worked with Source Safe on a large project they would know that changing your source control structure is incredibly painful to do, then to get the changes out to the other developers so that their VS.Net integration with VSS isn't totally messed up. Again, this is a specific set of tools that have this issue, and their mileage may vary since they may use something that makes this work trivial . They advocate test first development. Meaning, write the test, then write the code to make the test succeed. This is something I struggle with. I believe in test driven development, where you should have unit tests for all code that may break, but I don't write the test first very often. Perhaps I should, since in the talk by Brad and Krysztof at PDC they talked about writing code snippets of how people would use an API before even writing the API. By giving examples of how someone would use the API you learned what made its usage easy, then planned the API around that.
Overall I thought it was a great book. The concepts were simply stated and then hammered in. I would like to be on an XP project sometime to see just how well it works out. It seems to be a great companion to the Time and Materials projects, but seems like it would just fall apart in a fixed bid situation. Especially the idea that the customer can swap things around as they choose. I can’t say it wouldn’t work because I have seen it done by people very familiar with the XP methodology.
Have you used XP on your consulting projects? Did you have a hard time selling it to your customers? What parts worked? What was hard to adapt to?
Rating: 3 out of 5