Architecture By Baseball: Coaches

This is the fourth in a series of blog posts 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.

Coaches in baseball are unique in a couple of ways compared to the coaches in other sports.  One of the most obvious differences is that in baseball, the coaches actually wear the team uniform.  I personally cannot think of another sport where this is the case.  In some other sports the coaches actually have to comply with a dress code that is vastly different than the players (I think it is the NBA that requires the coaches to wear coat and tie when they are at court side).  Not only do the coaches in baseball wear the team uniform, but they are assigned a number just like the players on the field.  The coach is really a part of the team.

Another key difference between coaches in baseball and coaches in other sports is that two of the coaches in baseball are actually allowed on the field of play during the game.  On the first base and third base lines there are two coach’s boxes where the team can choose to have a coach positioned during the game. 

There is a distinction between this and other sports that allow coaches on the sidelines (such as soccer, football and basketball).  When a coach is on the sidelines in those sports, they are totally out of the field of play.  A ball that leaves the field of play is dead.  In baseball the foul territory where the coaches stand is still in play, so a player can catch a foul ball in the coaches box and the batter will be out.  A ball can be overthrown during a play and hit a coach, interfering with the play; there are even special rules that govern when this happens – which is not very often, because the coaches are usually pretty good about getting out of the way.

The coaches in baseball are literally feet away from the action and are able to interact with the players in a deep and meaningful way.  When a player reaches first base or third base safely the coach can give him encouragement and intelligence about how the pitcher is delivering the ball to the plate.  This can help the player decide if this is a good time to attempt to steal a base or take only a short lead off of the bag (to avoid a pickoff move).

The third base coach is an integral part of the action when there is a man on base and there is a ball hit deep into the gap or down the lines in the outfield.  As the runner on the base is rounding third a split second decision has to be made to send the runner to home or to have him hold up on third base.  The player is in the worst position to make this decision, as his back is to the outfield.  The third base coach is the one who makes the decision to send the runner or not.  If you have ever been to a game in person, nothing is more dramatic that seeing the third base coach swing his arm wildly, followed by a close play at the plate.

So what can we as software architects learn from the coaches in baseball?

Wear the Uniform – Often times I see people make too much of a distinction between the architect and the developers who are working on a software development project.  This can manifest itself in a lot of ways, and many of them are bad.  The role of the architect is different than the role of the developer, but they should be seen as one cohesive team.  This statement applies equally well to the designers, testers, DBAs, server tech and project managers on the team as well.

Be a part of the action – Architects are sometimes referred to as Ivory Tower dwellers.  Sometimes this is meant as a joke, sometimes is a half-joke and other times it is just downright true.  As an architect we should strive to be as close to the field of play as possible.  The perception when you are away from the field of play is very skewed.  Get out of the Ivory Tower (maybe press box is a better analogy) and get into the coach’s box.

Be a coach – One of the things that I did not note in particular when talking about the coaches is that most of them are former professional ball players themselves (I don’t think that is unique to baseball coaches).  They bring with them years of experience that they can impart to the players them are coaching.  Most of us who carry architect in our title were at one time developers ourselves and as a result, we carry with us many years of experience.  In addition to architecting the application, we can make the team more successful by sharing our knowledge with the team. 


One thought on “Architecture By Baseball: Coaches”

  1. Great series of articles. I love using life as an analogy for the way we architect and build software. I am going to start forwarding this to aspiring architects.

Leave a Reply

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