Architecture By Baseball: The Managers

Ron Washington Thrown Out of the Game by Rich Anderson used under Creative Commons

This is the fifth 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.

The last post in this series was called “Architecture By Baseball: Coaches“, where I talked about how the software architect can work better with the development team by emulating some of the things that a baseball coach does. Baseball is a little different than other sports that have a Head Coach, in baseball the team leader is the manger. Like the rest of the coaching staff, he wears the team uniform. The manager extra responsibility of thinking tactically and strategically during the game and throughout the season.

Tactical during the game

When a player comes up to bat and there are men on base, the manager will often times give the batter instructions about how he is supposed to bat. If it is a close game with a speedy runner on board, he may be instruction to bunt (called a sacrifice), rather than try to hit safely. The manager is giving up an out in order to advance the base runner (this is a very tactical move). Similarly, the manager may give the runner on base the “steal” or the “hold” sign or the “green light” to steal if they feel comfortable doing so. These choices are not as obvious as they may seem, the manager may chose to give not have the base runner the steal sign even if he is very good at stealing because it might prematurely end the inning. Nothing is worse than taking the bat out of your best players’ hands by ending the inning on a failed steal attempt.

Strategic during the game

The manager must also think strategically during the course of the game. The strategic decisions start actually before the game begins, when the manager fills out the line-up card. The line-up card is the list of 9 players (or 10 players in American League Baseball) that will start the game and what positions that they play. There are a lot of factors that play into the line-up cards on any given day: the opposing pitcher, the historic match-ups, etc. As the game goes on, there a limited number of players available to the manager during the game for substitutions (25 total players for most of the season and up to 40 for the last month of the season). The manager must make sure that the best players are on the field at any given time, but they cannot replace players constantly during the game, because unlike many other sports, once a player leaves a baseball game they can not return. As the game goes on the manager must know when to replace players for fresh players or specialist (pinch runners who are fast, or players who are better at defense).

Strategic beyond the game

Baseball has a very long season with many games (more than twice as many games as most other sports). The manager must remember this as they are making decisions. The manager must make sure to give most players a day off here and there throughout the season (there are a few super human players that never need a day off). The manager must also be careful to not over use the starting pitchers or the relief pitchers during a game, as it can be costly to make the wrong decision.

Software Architects: the balance between strategic and tactical

Like the manager making the scorecard, the architect must make a lot of decisions before the game (or construction) even begins. Scope is negotiated, technologies selected and proof of concepts identified and executed. Once the work actually begins, there are dozens of tactical decisions that must be made, but the strategic goals needs to be assessed. Communication is very key as these decisions are being made. The manager in baseball has to give signals to the batter, catcher or base runner. The software architect also has to communicate to the team members effectively so they understand what to do tactically, but he also needs to impart the strategic thought as well (so actually we have it tougher than the baseball manager).  You also have to get the most out of the development team (even if they don’t report to you directly). There is a great quote by one of my favorite baseball managers that talks about this:

“I don’t think a manager should be judged by whether he wins the pennant, but by whether he gets the most out of the twenty-five men he’s been given.” –Chuck Tanner

There is no book in baseball or software architecture

Many of the tactical decisions that I talked about have “conventional wisdom” answers to them. For example, man on first with 0 or 1 outs and the pitcher up to bat, the pitcher should bunt. This style of management is called “by the book”, which is a reference to a mythical set of rules that contain the answers to all situations. You can imagine the software architecture equivalent. If it is a function that is needed by more than one platform, or is called by 3 or more applications, it must be implemented as a SOAP Web Service. That may apply is many or even most situations, but there is no book of rules to follow in software architecture. There is another quote that fits this notion as well:

“The Book is nothing but a piece of garbage. My book is me.” –Chuck Tanner