Architecture By Baseball: Moneyball

This is the tenth in a series of articles about how we can learn about software architecture by studying and comparing it to the sport of Baseball.  This series was inspired by the book Management by Baseball.

I started this series off with a discussion of the 5 tool player, which is supposed to be the highest compliment that can be given to a player, especially when they are being scouted as a prospect.  I have gotten a lot of good comments about the article in the months since it was published.  I also used it as part of our recent ArcReady series of presentations on software architecture.  There are some critics of the 5 tool player in baseball, this article will discuss the criticisms and how we can apply those criticisms to software architecture.

Moneyball

Moneyball

In 2004 the book Moneyball: The Art of Winning an Unfair Game by Michael Lewis was published.  Michael had spent a couple of years following the Oakland Athletics and more specifically the General Manager of the team, Billy Beane.  Billy Beane was a highly touted prospect who was heavily scouted while he was still in high school.  He was the very definition of the 5 tool player.  He was drafted by the New York Mets in the first round (which is a huge deal if you don’t follow baseball).  As a major league baseball player, he was pretty much a total bust.  After 6 years he had played in a total of 148 games and batted only .219 with 3 home runs.  Certainly not what you would expect from one of the most highly touted players.

Don’t feel bad for Billy Beane; his baseball career was far from over.  He went on to be one of the youngest general managers in baseball and guided the Athletics to the playoffs several years in a row.  How he accomplished that with the Athletics being one of the small market teams is the subject of the book.

Moneyball is about how Billy Beane and the Athletics used some unconventional thinking to accomplish their feats with a much smaller payroll than the other major league teams they were competing against.  One of the tenants of this philosophy was to never draft a player like Billy Beane.  They thought that just rating players on the 5 tools was not enough to judge how they were going to perform.  They also felt that drafting players out of high school was not a good return on investment; college players were several years older, more experienced and you could judge better how they were going to perform on the field.


Software Architecture, like baseball is a people game

I am not going to spend the balance of this article refuting or analyzing the tools that I put forth in the first article in that series.  I have talked with enough software developers and architects to know that all those skills are important.  I want to talk about the importance of people to software architecture, because I think that we as an industry focus too much on everything but people when we are making decisions. 

Baseball is a people game; the players that you have on the field, on the bench and in your farm system are your primary asset to make your organization successful.  Yes, new stadiums help and they do draw extra fans, but nothing will draw better than a winning team.

In software architecture we spend too much of our time focusing on everything but finding, staffing and developing our teams.  We spend endless time arguing platforms (Windows or OSX, .NET or Java, PHP or ASP.NET or Silverlight or Flex), languages (C# or VB.NET, C or Objective C, XAML or mXML) or software packages (Dynamics or SalesForce.com, SQL Server or Oracle).  We also spend too much time worrying about the hardware portion of a solution (yeah I know hardware can be fun, but it is such a small part of the true costs of the solution).

The truth of the matter is that good architects and developers will exceed regardless of which platform that you give them, what language you ask them to code in and what software packages they have to build with.  Don’t get me wrong, they may grumble and complain about what they are doing, but they will achieve success.  Like baseball, we need to set out with the mission of getting and developing the best architects and developers possible, no matter if you follow the 5 tools approach or more unconventional approached like those in Moneyball.

One thought on “Architecture By Baseball: Moneyball”

Leave a Reply

Your email address will not be published. Required fields are marked *