|
My criticsm and comments
It was more than 2 years I was working in an XP team when I read this book. As a consequence, I was already having my habits (whatever they were good or wrong) and my team was working in a smooth way, living on its certainties. We had learned XP, clearly adopted it, and for sure adapted it.
It's also a long time that I implement design patterns. I usually adapt them or combine them so they better stick to my functionnal and implementation need. However, I like to go back regularly to the GOF to re-read the theory of the pattern(s) I want to put in place. What for? Just to get back to the definition and to appreciate more in detail any delta I was thinking to do. After that, maybe I will not change my implementation idea but at least I had been focused on all differences between my idea and the theory, and had forced myself to wonder why I was thinking to do that or that change. It helps me doing my job in a more clever way, letting me ask the "Why" towards my solution.
I see this book in the same way. It has allowed me (forced me?) to go back to the definitions, and most of all to the definitions given thru examples. Clearly, it made me look deep at each step of our XP stack to see what we were doing, if it was working good or not, if such or such difference was needed or not. It does not mean that we have drastically changed everything after that but clearly the interrogation is the first step to do before taking actions, and these examples gave me some directions where I wanted to go.
How does it work in practice? The author present us a small XP team: a few (named) characters having all their own personality and domain of competence : from the client, including the expert, to the stressed guy seeing insurmountable difficulties in all places. (Come on, we have all met a guy like this. Maybe yours won't scream "Panic !!" each time, but it will for sure tell very often "Gonna be hard", "It's not won in advance" or "I have no idea of how we can do that". Please... just come with positive mood, and with solutions... It's in moment like that, that I like the most the Shaddock philosophy...)
We are following this team among all the phases of a project development: analysis, development, refactoring, spiking, planning game, ... Each "act" will be described with some team dialogue, to put these personnages in action. And in most of the parts, some exercices and code example really place us as privileged spectators, in the center of the arena.
A sentence to remember?
Two in fact. First of all this book reinforce the fact that XP (and agile methodologies in general) will better fit to a team composed of mature developpers, with solid notions of simple design and conceptions. Did I said simple? This is the other fact I like to mention when I can.
"Simple does not mean easy. Developpers who are starting out often misinterpret this as "Do the easiest thing you can possibly do." This is incorrect; simple is often a lot harder to achieve than complicated. [...] The switch statement is easier to write, but the polymorphism provides a simpler solution."
The last word? This is an easy reading book, done in a clever way, didactic and fun, but highly serious at the same time. A "must-read" book to place in the hand of all XP team (beginners or not) and to be seen as an external third-eye. My only real criticism? Well... it has not been read by all of my team members. But can we really blame the author?
Want to find more about the books I have read ? Go to my bookshelf to find the few criticism I have already made !
|