Show Me The Moneyball (software edition)

Last week, I sat in on a great course from a group down in Austrailia known as Readify.  They are doing some great work down there and they offered to let me audit a course on .NET known as Industrial Strength .NET.  To sweeten the pot, they even offered to let me extend the offer to another member of the p&p team.  To my good fortune, none other than Ward Cunningham took me up on the offer.  But he was also clear on how we'd proceed--time for some pair programming. 

 

For those of you who don't know, pair programming is part of Extreme Programming (the "other XP"), the agile development methodology that completely changes the way development is done.  Unit tests, managed scope, iterative development, and pair programming are all included.  A few months ago, I told Jim Newkirk that I wanted to learn more about XP and he handed me Kent Beck's book.  I read it over a weekend and was extremely impressed (no pun intended).  A lot of great ideas that threw out tired conventional wisdom in exchange for exciting new ideas.  This was the "Moneyball" of software development. 

 

For those of you non-baseball fans, "Moneyball" is Michael Lewis' novel on the unique tactics of Oakland A's General Manager Billy Beane and how he has overachieved with a tiny budget by forgoing conventional wisdom for unique scouting and player assessment tactics.  Whether you are a baseball fan or not, I highly recommend you check out that book as it's a great example of how you shouldn't be afraid to challenge your thinking.

 

Anyway, Beck seemed to describe a movement similar to the Moneyball thinking that was starting to take over baseball (since the book was written, the Blue Jays and Dodgers hired GMs that were disciples of Beane).   Beck described a bunch of great ideas that I thought would be great for patterns & practices (and actually were implemented in Enterprise Library).  However, just like Lewis' book on Beane, I didn't agree completely with everything in the new movement.  In Beane's book, he seemed to downplay the importance of a good closing relief pitcher and overemphasize walks a little bit.  In the case of XP, the pair programming concept seemed a little bizarre to me.  As a coding control freak, it seems hard for me to understand how to watch someone and not get frustrated.  Or worse yet, I hated the idea of someone looking over my shoulder and seeing the weaknesses in my code.  But when Ward (who, along with Kent, has been one of the founders of the movement) offered to pair up with me, I figured it was like learning how to play basketball by practicing with Michael Jordan.  So I agreed…

 

It was interesting.  I definitely gained a new respect for what it is trying to accomplish.  The first thing you need to do is check your ego at the door.  If you don't something wrong as the driver, accept it.  If the other person is driving and does something you don't like, be prepared to realize it's being done better than your plan.  I learned a few cool new tricks from Ward and Ward picked up a few pointers from me.  Each day we did this (I sat in for three days), I got more and more comfortable with the idea.  I guess Kent and Ward were on to something here.  Would I plan to code my future projects as part of a pair?  I don't know if I am there yet.  But if Ward asks to join me for another project, I might just have to take him up on it.  And if the co-GMs of the Baltimore Orioles want me to come in and help put some new ideas into effect to finally field a winning team and end my misery of yet another disappointing year, I'll be waiting by the phone...

 

{No Music--Just the closing ceremonies of the Olympics}