Thanks for the review. On first reading, I quit about a quarter of the way through, at the third substantive error in fact, which the authors had been informed of in reviews and feedback from earlier material over the last few years.
A second reading shows that I might have been too hasty in turning off -- the long summary of the book might have been a simple paraphrase, reflecting only the authors' opinions and not those of the reviewer. By the end of the second reading, I'm still not sure which way to read it, so I'll give benefit of the doubt.
My second reading also revealed several other wilful misreadings and misrepresentations that the authors had published in earlier material, and had been called on. For instance, that "XP is risky": each of the practices in fact manages, in part or whole, at least one risk which prevents software teams from delivering software. Or that "XP is good only for maintaining software": in a sense that's true, but only because the first releasable build happens immediately and it's all maintainance upgrade from there!
Overall, I hope that the reviewer will have an opportunity to examine "Extreme Programming" further sometime later in his career. At the very least, that the negative spin by the authors on XP will not keep him from looking at other "agile" methods and practices which can benefit his team and his organization.
Actually, the "planning game" practices of XP were inspired directly by Scrum.
Scrum's concentration is on the project as a whole; XP's concentration is on the software team and making delivery of software reliable.
I'd take issue with you about whether your first "bad" point is bad. XP sets up so that you can (not must) deliver working software at any time. Having at least one new releasable build of software every day is an excellent means to that end. (By way of example, my team at Eidogen regularly creates between three and twelve distinct releasable builds each working day.)
I also would note that your second "bad" point that this is an incorrect characterization of XP. Developers are to be communicating all the time with the Customer, talking about what might affect functionality and estimates. If an issue doesn't have any effect visible to the Customer, then it's solely the developers' province.
Some folks prefer the "solo" form of flow. That's fine. XP teams work in a different form of flow, meant to produce visibly meaningful results with few or no defects several times a day. Pair programming is excellent within the cluster of practices for this purpose, in my experience with several teams (XP and non-XP alike).
Yes, that's what he's telling you. At least, that's what the authors of the book are telling folks. I do not know how correct that statement is, however, since my impression is that C3 was killed for political reasons unconnected with the project's progress. My impression of the authors, on other materials they have published, is not favorable either.
The basis of Extreme Programming, however, is reliably delivering software of value to your team's customer.
Yes, indeed. Elsewhere, Kent Beck describes that the basic ideas behind XP were drawn from what he learned from his father (an assembly-language programmer) about making maintainable software.
Slashdot Mirror
A second reading shows that I might have been too hasty in turning off -- the long summary of the book might have been a simple paraphrase, reflecting only the authors' opinions and not those of the reviewer. By the end of the second reading, I'm still not sure which way to read it, so I'll give benefit of the doubt.
My second reading also revealed several other wilful misreadings and misrepresentations that the authors had published in earlier material, and had been called on. For instance, that "XP is risky": each of the practices in fact manages, in part or whole, at least one risk which prevents software teams from delivering software. Or that "XP is good only for maintaining software": in a sense that's true, but only because the first releasable build happens immediately and it's all maintainance upgrade from there!
Overall, I hope that the reviewer will have an opportunity to examine "Extreme Programming" further sometime later in his career. At the very least, that the negative spin by the authors on XP will not keep him from looking at other "agile" methods and practices which can benefit his team and his organization.
Actually, the "planning game" practices of XP were inspired directly by Scrum. Scrum's concentration is on the project as a whole; XP's concentration is on the software team and making delivery of software reliable. I'd take issue with you about whether your first "bad" point is bad. XP sets up so that you can (not must) deliver working software at any time. Having at least one new releasable build of software every day is an excellent means to that end. (By way of example, my team at Eidogen regularly creates between three and twelve distinct releasable builds each working day.) I also would note that your second "bad" point that this is an incorrect characterization of XP. Developers are to be communicating all the time with the Customer, talking about what might affect functionality and estimates. If an issue doesn't have any effect visible to the Customer, then it's solely the developers' province. Some folks prefer the "solo" form of flow. That's fine. XP teams work in a different form of flow, meant to produce visibly meaningful results with few or no defects several times a day. Pair programming is excellent within the cluster of practices for this purpose, in my experience with several teams (XP and non-XP alike).
Yes, that's what he's telling you. At least, that's what the authors of the book are telling folks. I do not know how correct that statement is, however, since my impression is that C3 was killed for political reasons unconnected with the project's progress. My impression of the authors, on other materials they have published, is not favorable either. The basis of Extreme Programming, however, is reliably delivering software of value to your team's customer.
Yes, indeed. Elsewhere, Kent Beck describes that the basic ideas behind XP were drawn from what he learned from his father (an assembly-language programmer) about making maintainable software.