We started on Monday by creating Yet Another Rails app on my computer. It seemed very slow (again). We tried it on Chet’s machine, and his was again four times faster. So we restarted the UniBlue optimizers, which hadn’t been run for some 27 days. They run a long time but when they were done, my test time was back down to about the same as his.
Meanwhile we talked about what we would do if we were advising a team who had discovered that one of their computers kept going incredibly slowly. We considered a few options, some tongue in cheek:
- Convert to Unix
- Buy a Mac
- Use the fast computer
- Dig in and figure out what is going wrong and fix it.
- Run the optimizer every day.
More of the Same
Tuesday we ran into more problems. My machine was slow again, and when we finally got it going, MySql wouldn’t talk to Rails or to the PHP page. Then it turned out that MySql wouldn’t run on Chet’s machine either.
Wednesday we finally figured out that our MySqls not working was related to the “slimserver” running, the server for playing music on the SqueezeBox. We killed those and things worked. On Wednesday we managed to create the database (this is done by entering a single value into a single field on a web page. Not a very productive two hours.
We know darn well that a new computer would fix this problem for me. We actually shopped for one on the ThinkPad site. About $2500 and I’d be all set. But you know, I really haven’t been craving a new computer. Despite $500 off, last day of sale, I didn’t click the button.
In Zen and the Art of Motorcycle Maintenance, Robert Pirsig coined the phrase “Gumption Trap”. To quote:
Throughout the process of fixing the machine things always come up, low quality things, from a dusted knuckle to an accidentally ruined 'irreplaceable' assembly. These drain off gumption, destroy enthusiasm and leave you so discouraged you want to forget the whole business.
Pirsig, if I recall, goes on to talk about ways of pressing through or getting around gumption traps. On both Tuesday and Wednesday, I spoke with Chet at length about how much fun this exercise wasn’t. It’s not the most fun project anyway, and all this hassle is draining my energy for it.
Pressing On. Press "On" Twice = "Off"
Chet was off on Thursday, so we met today, Friday, at Borders. My machine was pretty slow, but a reboot fixed that. We ran a db:migrate to give us a place to set up the database fields. It ran for several minutes and then failed unable to connect to MySql.
Grr. Killed MySql and the slim software, which was for some reason running. Must look to see why that starts up. Tried the migrate again. Again it failed talking to MySql.
Another morning wasted screwing around. I am losing confidence. We talked about the overall cost of the project. Some of the items include:
- Create 3 Pages.
- Get Pages CSS'd for common look and feel.
- Create email when someone creates a new item, and a way for me to OK it.
- Import all the existing data into MySql.
- Get RoR running on my ISP.
- Bring up app.
- Deal with inevitable issues.
We think this project will cost us 2 1/2 or 3 weeks of our precious and supposedly fun two hour days. I think that many of those days will be filled with equivalent frustration to what we have experienced so far. I’m not in this to be paid in frustration, I’m in it to be paid in learning and fun. There won’t be much useful learning in this project, and it looks like there won’t be much fun.
As customer for this project, I am cancelling it. The value isn’t worth the price. The frustration of updating the page manually is less than the frustration of getting it automated. The value is less than the cost. Return on investment isn’t there.
I hope and expect that this little exercise will get some discussion going on the lists where these things come up. This may be a perfect, although small example of an “XP Project” that failed. It may be one of those examples where people want to pick at our process and see whether we “did XP right”. I’ll address some of the inevitable questions now, and more of them if and when they show up on the lists or in email.
As for the XP practices, we can tick off right here the extent to which we used them. I’ll use the XP1E list because it’s shorter and I know it by heart:
- Whole Team
- We definitely did this. We worked only together and the customer was with us all the time.
- Planning Game
- We did this, going over our stories and estimates frequently. It was the result of the final planning game that caused the project to be cancelled.
- Small Releases
- We were doing small releases, though they were all prototypes. We didn't deploy any, because my ISP doesn't have Rails set up. Our fear of how hard it would be to deploy, and how stable it would be, were part of why I cancelled.
- Customer Tests
- Didn't have any, but the customer was fully on top of how well things were working, and at the point we reached I'd not know how to suggest more tests than we had.
- Simple Design
- There isn't much simpler than following the Rails cookbook.
- Pair Programming
- Every minute.
- Test-Driven Development
- We didn't do this. We didn't, and don't, see how given how thin the app was. Lack of tests doesn't seem to us to be related to the cancellation.
- Quite a bit. That's kind of how you do Rails. Tests were all manual, but none caused trouble.
- Coding Standard
- Sustainable Pace
- Two hours a day. If that ain't sustainable, what is? (However, two hours of absolute frustration is a long time. As Chet puts it, overtime is any time when you wish you weren't at the office.)
- Continuous Integration
- Every minute.
- Team Code Ownership
- Totally. Mi code, su code.
- Aha! We didn't have a metaphor!!
Therefore, we weren’t doing XP and therefore XP didn’t fail.
No. Clearly not. Given the scale and size of what was going on, and the fact that despite it being elapsed weeks it was just a few full days of work, even I wouldn’t berate a team very heavily for “only” doing XP as well as we did.
I don’t think XP failed. I think it is reasonably fair to call this an XP proejct and the project certainly failed, at least in the sense that it never shipped and never delivered any value. If I were contracting to do this project, and I had cancelled it right out from under me, I would certainly be disappointed.
But as the product owner, I am now convinced that the price wasn’t worth it. And as one of the programmers, I am relieved as well as disappointed, because I won’t have to slog through this any more.
This is surely the most ignominious debacle of a project listed on my site, even though others have also not shipped. (Sudoku did not ship and will not. Shotgun will go forward if the Customer wants to.)
What do you think? Failure or success? Bad or good? Devil or angel? Let us know!