Neapolitan XP
Another idea for my process name could be "Neopolitan XP". To be honest, XP is my least favorite of the so called Agile processes. Honestly, XP is the least agile because it is so necessarily rigid. In Extreme Programming Refactored: The Case Against XP, Stephens and Rosenberg launch a knock-downdrag-out no-holds-bar attack on Kent. This book is easily as relentless as it is poorly written. Maybe Kent deserves it...but none the less just like TV Wrestling it make all parties look pretty bad.
What I would like is something as far from "Vanilla XP" as possible. There has to be a balance between the rigid prescriptions of XP and a directionless free form dance with no cohesion to the process that results in just being "Agile".
The book does make some good points. We (the developer) can't put everything off on the "customer". We certainly can't do EVERYTHING for them, but they ARE a customer.
The book suggests that pair-programming and design documents are mutually exclusive needs. If you have one, you don't need the other. Unsurprisingly design documents are the more attractive proposition of the two.
Knowing when not to refactor is a problem I stuggle with constantly. I still feel that somewhere between reasonable prefactoring and planned, constant refactoring there is a better way to work. The issue with refactoring production code is important to consider. All the testing in the world won't catch every obscure problem that could occur when a refactor goes wrong.
One concept mentioned in the book I disagree with. It talks about "refactoring interfaces", specifically not to do it (220). Interfaces are not a program, interfaces are redesigned not refactored. The code that generates the interface can be refactored, but that should result in no observable change. The code that generates the interface can be changed to change the interface,but that is not a refactor. Refactoring belongs to a different concern in the domain of applications than interfaces. Similarly, data is not "refactored". Refactoring should have no net effect on the observable functional behavior of a program. It might make the program run faster, use less memory, maker fewer DB calls, etc, but in general the user of the program should see no functional change. Refactoring is applicable to databases. As originally envisioned by Cobb, databases are accessed through a sort of "sub language" and so are in essence a program.
On the subject of Use Cases, Cockburn's "6 bits of precision" is referenced:
- Bit 1 - Name Goal
- Bit 2 - Describe Main Scenario (this is the level of resolution in an XP "User Story")
- Bit 3 - Failure Conditions
- Bit 4 - Failure Actions (level of resolution in traditional Use Cases)
- Bit 5 - Data in/out Description
- Bit 6 - Recipient of the message (level of resolution in Catalysis)
There is a difference between an iterative spiral and a never ending loop. Stephens and Rosenberg suggest that XP embrases the later, but both the argument to embrace such a thing and the suggestion that anything as often discussed as XP would seriously do so it preposterous. This underlines the primary flaw in the book, anything taken to the extreme is easy to pick appart. Doing so does proponents on both sides of the argument a disservice. The attack on YAGNI is the crippling chink in this book's armor. Out of all of the XP tenants, YAGNI is the most sound and well established priniciple in software development.
One thing I like about Scrum is it makes a disctinction between an iteration and a delivery, specifically each delivery is one or more iterations. In XP there is no such distinction. The two are the same. Constant stream of value and constant integration has merit, releasing early and often does not.
Task cards are useful. They can take many forms, but they are definitely useful in team work. Jira's implementation of Task cards results in high-value-low-overhead.
The authors' denial that interim releases have value is laughable. Anyone that has tried and succeeded at this knows the value. This isn't universally valuable, and in teams still learning to be Agile it is not even cost effective. The authors' rejection that people involved in a process, not the smart-alec authors that use that project as a case study for rhetoric in a book, are the party truely qualified to define success is also laughable. If a team learns how to better work together better through trying XP, even if they don't adopt "Vanilla XP" in future projects, then XP has been successful. It seems the authors ignore the primary focus of XP, people.
Sadly, it seems that the Stephens and Rosenberg devoted more time to thinking up parody lyrics to pad each section rather than actualy writing the book. This might explain why it so often slips into an overly irreverent hen peck of XP. The arguments are too far-stretched to be credible. Contrary to the foot note on page 372, this book isn't worth purchasing, nor was it worth it in 2003 when it was first published.
Learning from other people's mistakes when formulating your own process is bound to be only slightly less effective than making your own. I, like the author's had an initial, "ZOMG, what is this pinko crap?" reaction to XP. The difference is I wrote a blog article about it before I realized there were some scraps of value, rather than over 350 pages of diatribe.