This book explores the XP hype and discusses the problems. In the end the best parts of XP will be used in the writers own software engineering process.
The first part gives a summary of the XP process and the problems with the c3 project of Daimler-Chrysler. This is the project that is talking about to prove Xp can be used in larger projects. By using excerpts from a number of wiki resources they tend to show the problems with the c3 project. The following resources are good to read.
Interesting wiki page, fun to read. But the finesse is at the end. In fact the most important part of the part is rewritten about 15 times:
“Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren’t the same. The customer feeding stories to the team didn’t care about the same things as the managers evaluating the team’s performance. This is bad, and we know it’s bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over. Or not, we’ll see…” — KentBeck
The discussion whether the project is a success or not is hard. It did come to results within 11 months that are still used. Other projects trying the same did not succeed at all. However 4 years of hard work did not nearly reach the state of providing the complete system. I guess Xp is hard to be used in a project that takes longer than about 3-4 months. But the biggest problem is the lack of design and specifications. I believe in the goal oriented design and the use of personas. See the book “The inmates are running the asylum”.
The stuff of Xp that is very good to use:
test-driven development, continuous Integration, Coding standards, release soon and often, interaction design and pair programming.
One important remark for pair programming, use it wise. I have the same opinion as the writers of the book. Only use pair programming for the hard part of your system.
The following excerpt from the book made me laugh, but I think it is very close to the truth.
“XP is a methodology creates by programmers who are sick of management telling them that they can no longer just code, but they must follow a formal methodology. XP’s main tenets are all very programmer-centric and often fail to consider the larger scope of a software development project.”
This something we have to learn from within our gridshore philosophy. We must take care not to make it a programmers game. We need to have good designers (interaction, interface and software) as well.
The final chapter of part one discusses what can go wrong with the XP process. This chapter introduces the concept of the circle of snakes. Each snake represents one the practices of xp. What makes it interesting is that each snake can only be made safe by daisy chaining it to the next snake. I’ll give an example by one of the snakes.
Emergent design means that very little time is spent designing the system before coding begins. The overall design and architecture will morph many times in the course of the project. But the lack of significant upfront design is considered “safe” because the code is being constantly refactored.
Why is this rng so interesting, since failing with one of the snakes makes the complete process instable. It is very hard do all snakes right, therefore the process is hard. A process should not be hard to use, if one of the snakes fails the process should have contingency build in.
One of the things they keep referring to is throwing yuor code away at 5 oclock if it does not integrate. see the following url for an image of the process
I am curious what the book will bring in the following parts, more to follow …
This page was written over 2 posts before, now on one page
I made through the complete book. An interesting but rather long read it was. First some general remarks. I did like the book, well at least the first 100 pages. Then to me it was more of the same. The satirical songs and stories began to iritate me. The number of references to other parts of the book are way to much as well. Nevertheless, I did like the book, some conclusions are a bit harsh. The book gives some refactorings to the XP process to make it better. The best thing is that the book makes you think about your own process while developing software. Should you read this book? Tough question, if you have the time I would most certainly read it. If you do not have the time, you can allways jump to the conclusions of most of the chapters.
The book consists of a number of parts each containing a number of chapters.
This section gives a short introduction about XP. It discusses the values of XP, the 12 practices, the roles and the activities.
I think the best lines that tell you how the writers think about the book are these.
“XP is a methodology created by programmers who are sick of management telling them that they can no longer just code, but they must follow a formal methodology. XP’s main tenets are all very programmer=centric and often fail to consider the larger scope of a software development project.”
The next chapter discusses the famous XP project C3. Some of the project members were Kent Beck, Ron Jeffries, Martin Fowler, Chet Hendrickson and Don Wells. There are a lot of quotes and references to the wiki website and to other resources on the web. This way you can create your own opinion. The discussion whether the project is a success or not is hard. It did come to results within 11 months that are still used. Other projects trying the same did not succeed at all. However 4 years of hard work did not nearly reach the state of providing the complete system. I guess Xp is hard to be used in a project that takes longer than about 3-4 months. But the biggest problem is the lack of design and specifications. I believe in the goal oriented design and the use of personas. See the book
A few of the most interesting links are:
Chapter 3, the final chapter of this part introduces the twelve serpents and the circle of snakes. What they want to tell you is that every snake is made safe by the following snake, if one snake is let loose, the circle brakes and all snakes are on the run. The remainder of the book will discuss the snakes and refactorings that makes the process safer. The snakes are:
- No detailed written requirements.
- Emergent design
- Constant Refactoring
- Unit tests
- Pair programming
- Collective ownership
- on site customer representative
I’ll give an example by one of the snakes. Emergent design means that very little time is spent designing the system before coding begins. The overall design and architecture will morph many times in the course of the project. But the lack of significant upfront design is considered “safe” because the code is being constantly refactored. So if refactoring fails ….
They make it pretty obvious they do like some concepts, but you need to refactor them for your project.
One thing that made me laugh in the book was there way of discussing the 5 o’clock go home, anythin not done, throw it away XP practise. The following satirical quote makes it clear.
Child : “What did you do today, Daddy?”
Father : “I tossed out my code and went home clean. And tomorrow I intend to pair program and stare at someone else typing.”
This part is about the social aspect of XP. One of the things that remains in my head when reading this chapter is bout the blame when the project fails. Within XP it is the people who are to blame, since the process is good. If you think bad about the process, you are in fear.
The red line within this chapter is that being a customer is hard. Youe need to provide the requirements on story cards and prioritize them. You need to write runnable test scripts. When the project becomes to large you need to have a team from the customer. Because there are no written requirements the customers needs to talk with one voice. The solution is to have a customer available to an analist. The analist takes care of the requirements by analysing the customers needs and goals.
Pair programming can be helful when looking at tough problems. Pair programming with 100% of production code is extreme. People just cannot handle it being in one persons space with two persons all the time. On top of that pair programming is not the same as peer review while both are targetted at getting better code.
One of the things programmers hate most is writing documentation. That is possibly the reason why so much programmers love XP. I think the following quote from the book touches the heart of the problem.
Fowlers quote highlights the fact that design documents in XP are mostly transitory. This contrasts greatly with the notion of design documents in, say RUP, which calls all items of ducomentation artifacts (which suggest documents that are long-lived and may be dug up several years later). Although this notion may at first seem absurd, the maintenance team who actually do need to dig up that documentation several years later will offer a prayer of thanks to the previous team members for their forward thinking.
Within RUP it is important to decided what to document. Ask yourself the questions: Who is going to use it? Who is going to miss it?
It does not take courage to stop writing documentation. It takes courage to take a product into maintenance without documentation.
Design after first testing
No BDUF – Big Design Up Front, this probably one of the biggest issues the writers of the book have with XP. I strongly believe that Design upfront is very important. This does not mean that writing tests upfront is wrong. Writing unit tests upfront does make you think about what to write before you write it. This also valid for design and analysis. Therefore test driven development is important, but equivalent to design upfront. In fact they complement each other. The chapters contains the following lines by David Van Der Klauw which I find interesting:
My concept of bug finding is something like this : A programmer should find 9/10 bugs before check-in, the automatic tests should find 9/10 remaining bugs before hand over to QA, QA should find 9/10 before handover to customers who will again find 9/10 the other 1/10 will never be found. Therefore the customer only sees 1 in a 1000 bugs
Morale, if you release to soon to the customer, he sees to many bugs and looses interest in the product.
Constant refactoring after programming
Refactoring is not bad, that is clear. However, constant refactoring code that works fine is not allways good. Why keep changing code just because it smells bad. So use refactoring when changes are necessary for requirements changes, bugs, or after a code review, but know when to stop.
Another thing about refactoring is UserInterface refactoring. Especially within XP, the users get to use the product very soon. But refactoring the UI makes the users look for functionality every release. When the users get to use the product soon, you also must maintain the live data. Refactoring also leads to a database refactor. Be very carefull with production data. Make solid migration plans.
User stories and acceptance tests
With all requirements the analysis is very important. Within XP User stories are used. These are very short descriptions of what a user wants to do with the system. Comparing these to use case (RUP) is obvious. What is missing with user stories is the failure conditions and actions, or the rainy-day scenarios. The step between the user stories and real code is large. You need to do requirements as well as design. The emphasize within XP is on Code. If the user story is not clear, use the customer representative to make things clear. Problem is this extra information is only documented in the code. Refactoring and you can loose requirements. No problem, if the customer representative does not miss it with his tests then it was probably not important. Another part that is hard to graps within user stories, especially since the customer should write these are the non functional requirements (FURPS+)
Part III, IV and V
To be honest, this is the moment where I started to loose interest. More of the same, sometimes in other words, there are a few statements that I want to mention and some good references.
Interesting subject about fixed scope, time, budget. This leaves just one parameter open and thats quality. You cannot make them all fixed.
Another thing that struck me it the use of frameworks. The book states this is not done within XP since you will never find a user story that tells you to use a framework. I cannot image this is true. One of the reasons I think that this book is to extreme itself.
They are also talking about Emergent Architecture, this is achieved via evolutionary prototyping that ends up as production code. Looking at RUP for instance, you have early prototyping, the code is not used in the production code. Usually this prototyping is quick en dirty, just to see that it works.
That’s about it for the book. Hope this helps. I will use the gained knowledge to write down some theory in the wiki. I will close this review with a last quote, that applies to XP, but to some extend to the book as well.
I believe that a major flaw in XP is that it takes things to an extreme. I believe in doing things is moderation and trying to optimize the value by trading off one factor against another. In life, I fin that rarely is the optimum achieved at some extreme point.