Ron Washington Arguing the Home Run Call ...
By Rich Anderson
Used under Creative Commons

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

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 talk 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

Ron Washington Arguing the Home Run Call ...
By Rich Anderson
Used under Creative Commons

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

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 talk 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

Third Base Coach

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.

Coach

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?

Knuckles at third

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. 

Josh Holmes called me out me in the latest round of questions going around the blog world.  This one is interesting, because it has the blogger answer questions about how they got started in software development.  Here is the current stack trace:

Michael Eaton (post) -> Sarah Dutkiewicz (post) -> Jeff Blankenburg (post) -> Josh Holmes (post) -> me (answers below)

How old were you when you started programming?

This one is tough to answer, because I actually started twice.  When I was 12 years old my friend Jim got a Commodore Vic 20 and I used to "program" on it.  It mainly consisted of copied programs from the back of the computer magazines and sophisticated programs like:

10 print "My name is Larry"
20 goto 10

I lost interest in programming after a few months, mainly because we could never get any of those programs in the magazines to really work correctly.  Or it also could have been all that Men At Work that I listened to.

The second time around I was in college and I was 20 years old and got started because of a required class in college.  I went to school to study photojournalism, but had to take 2610 - Intro to business computers.  I was scared to death to take a computer class, I figured I had to get an A in every other class that semester to make up for the D I was going to get in that class.  Fortunately I had an awesome professor, Tom Marshall, who was a Phd student at the time, but now teaches at Auburn University.  Tom got me totally hooked on the computer / information technology industry and eventually into programming.

What was your first language?

BASIC and then COBOL

What was the first real program you wrote?

My first inclination was to answer with a program I wrote when I was out of college, because that is the first time most of us write "real" programs, right?  But I am actually going to answer this with some programs that I wrote my senior year in college.  I went to the University of North Texas and they had a great program for Management Information Systems (although they called it BCIS).  Their program was geared to teach real world skills, and they even had you writing on real mainframe systems.  Those also geared their curriculum towards real world problems and techniques to solve them.  The killer course back them was the database course, taught by Dr. Vanecek.  After 3 or 4 grueling projects where there was a "right answer" (you were trying to write programs that produced an exact result), everything was take off the table and you had to build an entire system in 3 weeks (while taking 3 or 4 other classes).  I learned a lot about time management in those 3 weeks.

What languages have you used since you started programming?

BASIC, COBOL, JCL, ADABAS Natural, DYL280, REXX, Smalltalk, Visual Basic (classic and .NET), Javascript, C, C#

What was your first professional programming gig?

My first job out of college was working for Mobil Oil at their data center in Dallas, TX.  It was a neat first job because I actually worked for the data center and not on business applications.  I got a real understanding of the operations side of the house that people who have only worked as programmers never get to see.  Also I was one of the few developers that worked there, most people were systems programmers.  So I got to write a lot of code for neat projects like replacing a quarter of a million 3480 tape cartridges, consolidating 2 data centers and performing disaster recovery tests (sometimes the tests are more complicated than the real disasters).

If you knew then what you know now, would you have started programming?

Yes I would, but I would do a couple of things differently.  I will tell you what one of those is in an upcoming blog post (I was already working on it before I got called out).

If there is one thing you learned along the way that you would tell new developers, what would it be?

I have used this line (or one similar to it) for over 10 years when I mentor people new to the Industry:  "Nobody ever became CIO by just writing code".  If you love to write code and that is all you ever want to do, please write code and perfect your craft (the world needs many, many more good developers).  If you have other aspirations, you need to diversify.  Learn about the database, learn about the infrastructure, learn about project management (I shutter when I say that).

What's the most fun you've ever had ... programming?

In 1996-1998 I worked for Compaq Computers in Houston, TX.  This was a different time in the industry than it is now, hardware still ruled.  While I was there we shocked the industry by releasing the first desktop machine that was priced below $1000 (and it did not come with a monitor).  I worked on a project to allow consumers to configure and buy computers in the retail stores.  We literally put the whole thing together in less than 6 months from bar napkin to full role out. I did a little of everything on that project : hacked database tables at night, troubleshot the Office Depot DNS servers (while in a store), created a caching system for images with ActiveX (along with J Sawyer) and even spray painted the prototype kiosk in my garage. 

I did not do a whole lot of programming on the project, my role was what we would now call a technical architect.  But I will never forget debugging some code on a Sunday morning so I could get the whole thing into production before I boarded a plane to New York for the press conference on Monday morning.  The marketing people were calling me and saying "they are boarding the plane right now", I told them I would catch the next flight.  They told me 26 hours later after the whole thing was working that they thought I was seriously ditching them.

Who am I Calling Out?

I had a fun time answering these questions, so I would like to pass the meme on to the next round of folks.  Looking forward to hearing from:

Dan Rigsby
Dave Bost
Brian Moore (post)
Damon Payne (post)
Chris Pietschmann (post)
Angela Binkowski (post)

Updated (6/10) The list was updated to include links to response posts.