Architecture by Baseball: Conference on the mound



The Conference by Nick Schweitzer, used with permission

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

I noted a couple of years ago that baseball was one of the few or the only sport that allowed coaches on the field of play, referring to the fact that when a team is up to bat, two coaches are allowed on the field in coaches boxes.  In addition, a pitching coach or manager is allowed to visit the pitcher’s mound when his team is in the field of play.  They are almost always joined by the catcher during the conference on the mound, but they can be joined by players from the infield as well (as the photo above shows occasionally you can get all the players from the infield on the mound).  The most common reasons for a manager to visit the mound are to:

  • Remove a pitcher from the game in favor of another pitcher
  • As a stall tactic to allow a pitcher in the bullpen time to warm up
  • Review the pitcher’s approach to the upcoming batter, especially when the batter is coming up as a pinch hitter
  • Coordinate the defense when there are runners on base
  • Calm the nerves of the pitcher in a big game situation

You can sum up all of these specific reasons for visiting the mound as needing to make an adjustment to the game plan.

In this series I have always drawn the parallel between the baseball team’s managers and coaches with the architects on a software development project.  I think of the players as the developers on the software development project.  I don’t mean to say that the architect is a higher level than the developers; it is just that their role is different.  The architect, like the baseball team’s manager, has to do a bunch of work upfront to line up the correct team and prepare them for the game.  The developer, like the baseball players, play just as critical of a role (or maybe more critical) in the success during the game. 

What I have not spent much time discussing in this series is how the architect and the developers actually communicate with each other before and during the software development project.  But the conference on the mound gives us a good chance to discuss how the developers and the architect can adjust the “game plan” during the project.

The team standup

I talked about Scrum a couple of years ago and I am still a fan of it, but the part that I have always liked the best was the daily scrum (sometimes called a team stand-up).  A stand-up got its name from the fact that the meeting was so quick and to the point, that there was no need to even sit down.  Even though traditionalists encourage the no sitting rule, it is often violated.  The “meeting” is a ~10-15 minute check point where all of the team members come together, and when done in the most traditional fashion, it looks a lot like Nick’s photograph above.  The main purpose of the stand-up is to frequently make sure that everyone on the team is on the same page and to identify any issues that need to be addressed.  Quick issues can be addressed in the stand-up, but more complex issues are deferred for a follow-up with just a subset of the team.  Scrum and other agile methodologies encourage this to be done on a daily basis, although in practice it can be adjusted to 3 or 4 times a week.

Not exactly like the conference on the mound

There is one key difference between the team stand-up and the conference on the mound in the game of baseball: frequency.  The strength of the team stand-up is that you are meeting quite frequently (even if it is for just a short amount of time).  That luxury is not afforded in baseball; you are only allowed to visit the mound once per inning.  A subsequent visit to the mound requires the pitcher to be pulled from the game in favor of a relief pitcher.  The purpose of this is to keep the game moving along, the game would get too long if they manager and other players were allowed to visit the mound as often as they wished.  Fortunately as developers and architects we have the luxury of frequency.

Architecture By Baseball: The Presentation

As I mentioned previously, I spoke to the Architecture Special Interest Group (SIG) of the Indianapolis .NET Developer Association (IndyNDA).  Steve Porter, who is in charge of the group, asked me to present when they founded the group last September and it took a few months for our schedules to align and I am glad that they did.  Steve asked me to do the “in person” version of my Architecture by Baseball series of articles.

I have to admit at first I did not see the value in standing up in front of a group and covering things that I had already written.  As I was putting the presentation together, however, I realized that there are a lot of things that I had not covered in the articles themselves add a lot of color to the topics presented in the written form.  I had a lot of fun putting the talk together (which I did at the last minute, the night before) and had even more fun delivering the talk to the group (about 35 people or so).    Thanks to Steve and to all those who attended the talk.

I promised I would make the deck available to the people there and thought I would share it here as well.  It is up on My Slideshare Account:

Architecture By Baseball: Spring Training

Photo Title

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

As a baseball fan, some of the sweetest words that you can hear are “Pitchers and Catchers report today”.  The pitchers and catchers are the first players to report to Spring Training, so when you hear that you know that baseball is on its way.  Spring Training is a chance for the players to get back into shape for the season.  It is also a time when young players get a chance to “make the big team”.  Managers will also use Spring Training to try players at a new position, make changes in the batting order and integrate new players into the team.  Spring Training also involves exhibition games that give the players a chance to experience game play before the official season starts.

The benefits of Spring Training for a baseball team can be lumped into one of three categories:

  • Getting back into “game shape”
  • Learning new skills / positions
  • Jelling together as a team

Spring Training for architects and developers

Typical software development projects usually have a ramp up period before the project is at full stride.  As a matter of fact I cannot recall any project that I have ever been on that did not have a quite protracted period of less than full productivity.  Requirements are still being gathered, environments (servers and desktops) are still being configured, software is still being procured, etc.  This can be quite a frustrating time for the developers, but especially the architects on the project.  You don’t have enough of the facts to design and build the real business application, but the clock is ticking on the project so the need to get started is pressing upon you.  I propose that you use the time to do some Spring Training.  The software development team should spend some time focusing on the same type of activities that you see listed above.

Get back into “game shape” – If you are starting a new release of an application chances are that you spent your past few week not writing new code, but stabilizing the previous release for shipment or doing post deployment activities.  The “new code” muscle has probably not been stretched out for a few weeks.  Practice writing new code from scratch, even if you don’t know if it will be used in the application.  Get those skills sharpened up so that when the rest of the project comes together you will be ready.  Don’t do this in the “prototype” throw away fashion, you may throw away the code in the end, but don’t write it as throw away code.  Write real code with unit tests, error handling, documentation, etc. 

Learning new skills / positions – If you are working on a new application or if you are new to the application there is a good chance that you will be working with unfamiliar technology.  You may be a fantastic ASP.NET Developer, but this may be your first project with ASP.NET MVC Framework.  Use this time to become familiar with the new technologies.  It also may not even be a new technology, but rather a new style or technique that you are applying.  Use the projects Spring Training time to become really familiar with the new stuff.

Jell as a team – Like baseball, software architecture and development is a team sport.  You have to be effective as a team in order to succeed.  Use the Spring Training time to get to know the new team members (if there are any) and to get accustomed to working well together.  As a quick aside you should be open to ideas that new players bring to the team, you should always be open to hearing best practices.

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.



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, 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.

Architecture By Baseball: The General Manager

This is the ninth 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 have previously talked about the unique role of coaches in the game of baseball and talked about the special role of the manager in the game of baseball.  The coaches and managers are responsible for making the team successful during a game and across the course of a season.  The manager will spend some time concerned with how the team will play in future seasons with some of the decisions that he makes, but ultimately his responsibility is the here and now.  In a great example of separation of concerns, the long term success of the team (or franchise) rests on the shoulders of another person:  The general manager.

The general manager of the team is an executive position within the business organization of the company.  They are responsible for the baseball operations of organization, but they are beholden to the business operations of the company that is the organization.  Some of the things that general manager does routinely in the organization:

  • Player transactions – staffing the 25 and 40 man roster as well as all the minor league franchises
  • Player acquisition and development – drafting and developing young players and acquiring veteran players via free agency
  • Staffing the coaches and managers – one of the most high profile activities is the firing of the team’s manager
  • Managing the costs of talent – the salary of the players must be weighed against team revenue and organizational goals
Branch Rickey
Branch Rickey

The Greatest General Manager of All Time?

It would be an incomplete discussion of the role of the general manager without mentioning the person who I think is the greatest baseball general manager of all time: Branch Rickey.  Like many General Managers, Rickey started off as a player in baseball before going into the business side of baseball.  He was a success General Manager with several clubs, most notably the St. Louis Cardinals and the Brooklyn Dodgers.  But what made him such a great general manager was things that he did that were innovative and beyond the traditional role of the general manager.

Re-inventing the game –  As the General Manager of the St, Louis Cardinals, Rickey created what is now known as the farm system.  The farm system is minor league baseball team that is affiliated with the major league or “big” club.  The Farm system allowed the major league team to develop and retain talented younger players.  Prior to Rickey’s innovation, the minor league teams could sell or trade their talent to any team.  The affiliation gave the major league club the rights to the player when they were ready for the big leagues.  This gave the Cardinals a distinct advantage over their competition for many years.

Breaking the color barrier – When Rickey was a college coach for a while and was appalled at the segregation that took place with players of color.  He vowed to do something about it and when he was the GM of the Dodgers he was finally in a position to take action.  He signed Jackie Robinson to a minor league contract and later promoted him to the major league squad, bringing an end to the era of players being denied the rights to play baseball.  This also gave the Dodgers (and the other teams that quickly followed them) a temporary distinct advantage in signing talented players that other teams passed on simply because of race.

These are 2 of the most notable things that he did – there were dozens of little innovations that he made to the game during his years as a General Manager.

Software Architecture General Managers

I have talked before about the different types of architects, but have tried to avoid the hierarchy of architects that some organizations put too much emphasis on.  But talking about the general manager creates a natural point to talk about the role of an Enterprise Architect versus a solution architect.  Enterprise Architects are responsible for the macro view of all the of the systems in an organization and with the long term health and strategy of those systems. 

Some organizations make the mistake of thinking of them as a “super architect” who should be able to do all the things that the other architects do.  Other organizations can make the mistake of thinking that the Solutions Architect should be subordinate to the Enterprise Architect.  Many of the soft skills are the same between the Solutions Architect and the Enterprise Architect, but we should think of them as separate duties, like the manager and the general manager in baseball.  Solution Architects have the scope of the solution they are designing and building and should be focused on the current version and maybe one or two versions out.  They cannot be hung up on the long term strategy of a service bus that is several years out.  The Enterprise Architect should also not be thinking too narrow on the here and now either.  They need to focus on the longer term and not any specific application.

Be like Branch Rickey

If you have the opportunity to be in a general manager like position, studying some of the things that Branch Rickey did is not a bad thing.  He used business process and radical change to accomplish great things.  He did not just focus on being the best general manager; he changed the rules of the game.  I love this quote from him:

“Luck is the residue of design” – Branch Rickey

Architecture by Baseball: The 2 Out Rally

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

One of the most exciting things at a baseball game can be the 2 out rally.  A 2 out rally is simply when a team has nobody on base, 2 outs and they put together a series of hits (or walks) that usually lead to one or more runs being scored.  All rallies are exciting, but a 2 out rally can be particularly exciting, because the team is down to its last out in the inning.  One bad swing of the bat can bring the rally and the inning to a close. 

Probably the most exciting of the two out rallies comes when not only is the inning on the line, but the game is as well.  This comes when the home team is behind (or tied) in the bottom of the 9th inning.  It can get to the point where one swing of the bat can win or lose the game.  There is a real excitement as the hometown crowd cheers their heads off for the rally to continue.

I remember Gene Mauch doing things to me at Philadelphia. I’d be sitting there and he’d say, ‘Grab a bat and stop this rally.’
Bob Uecker

Exciting and Nerve Wracking

If you are a baseball manager you like the 2 out rally, but you would much prefer for the rally to start with no outs.  Probably most players feel this way too.  2 out rallies are very exciting, but they come with the high price that one mistake and the rally is over.

2 out rally in Software Projects

I have never been on a software project where the work was distributed evenly across the time allotted for the project.  If you have 6 weeks to complete the project, you would assume the best way to accomplish the project would be to do roughly 1/6th of the work in the first week, 1/6th of the work in the second week and so on.  I can point to some literature on this, but I think I will keep this anecdotal, because everyone who is reading this article is either nodding along or chuckling at how true this statement is. 

Development teams just don’t “pour on the gas” until the deadline is fast approaching (or as I like to call it, until there are 2 outs).  I have been on projects where we did about 25% of the work in the last 10% of the project timeline.  Through lots of heroics and many long hours in the last part of the project, we usually have gotten something put out by the deadline.  When we haven’t it is usually because one thing tripped us up (like an infrastructure issue or a bug that is hard to track down).  In baseball terms, this is the one bad swing of the bat that killed the rally.

Architecture has an even harder time with 2 outs

Thus far I have been talking about the habits of the project team a whole, and not necessarily about the role of the software architect.  There is a special burden on the software architect to get moving on a project before there are “2 outs”.  A solid architecture needs to be in pace early and all outstanding issues need to be resolved before the pressure of the project deadlines are upon you.

There is another thing to note as part of this discussion.  Baseball is a sport that is not judged by time.  As long as the team keeps hitting, the game can literally go on forever.  How long the game took is merely an interesting statistic that gets put in the record books.  Software projects are usually not so lucky – there is almost always a deadline involved.

Since baseball time is measured only in outs, all you have to do is succeed utterly; keep hitting, keep the rally alive, and you have defeated time. You remain forever young.
Roger Angell

Architecture by Baseball: Stats

This is the seventh 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 don’t think baseball could survive without all the statistical appurtenances involved in calculating pitching, hitting and fielding percentages. Some people could do without the games as long as they got the box scores.” – John M. Culkin

Did you know that for the current season right handed batters that face CC Sabathia (the pitcher in the photo for this article) are batting .218 against him (which is a good opponents batting average for a pitcher)?  But against left-handed batters his opponents’ batting average is a fantastic .136? 

Did you know that the 1888 Washington Senators had the lowest team batting average when they batted a mere .207?

Did you know that Cal Ripken, Jr., who is best known as baseball’s “iron man” for playing in 2,632 consecutive games, is also the all time leader for grounding into double plays with 350 of them over his career?

All professional sports have a battery of statistics that are tracked as part of the game and the subsequent reporting of those games, but most people would agree that baseball statistics are far more numerous and are actually a part of the fabric of the game.  One of the most fascinating aspects is how we use statistics to compare players from different eras.  Because the game has evolved slowly over the years and has not been radically redefined along the way, we are able to make meaningful comparisons.  As a result we can meaningfully compare the consecutive game hitting streak that Joe DiMaggio had in the 1940s, with the one that Willie Keeler had in the 1890s to the one that Pete Rose had in the 1970s.

More than just being a history lesson and interesting footnotes to articles about games, statistics are actually used in the decision making process before and during a game.  A manager (as an example) may look at the matchup between the batters in his lineup and how they have fared against the probably pitchers for that day’s game.  He may chose to give a batter the day off as a result of this.  The general manager will also use statistics to judge whether they should draft a player, or sign a particular player as a free agent.

As much as statistics are important in baseball, we should remember the role of statistics is to enhance the experience, not to become the experience.  Don’t spend all your time computing the batting average of the player coming up to bat with runners in scoring position (RISP) with less than 2 outs, which is a statistic that you will hear of frequently.  This quote says it best:

“Baseball isn’t statistics – baseball is (Joe) DiMaggio rounding second.” – Jimmy Breslin

Software Architecture Statistics

Software engineering has some really interesting statistics that are used as part of the development process.  Some of the most common or the most interesting statistics are:

  • Lines of code – when we are working on an application, particularly one that already exists (a legacy application), the number of lines of code is an interesting piece of data.  For example, if you are going to make major changes to an application it will be a lot easier to change one that has 100,000 lines of code than one with 2,000,000 lines of code (just due to the sheer size of the application).
  • Cyclomatic Complexity – measures how complicated the application is by analyzing the number of paths through the program.  This adds some “depth” to the lines of code statistic, because a program that is 50,000 lines of code can be much more complex than one that is 100,000 lines of code.
  • Function Points – a way to calculate the size of an application by how many things it does.  Function points are very user centric, so “back end” applications are skewed a bit in the number of function points.

While software architecture has some interesting statistics, we as an industry do not use them as much as we should (this statement is part opinion and part anecdotal observation).  We also fail horribly as an industry to track statistics over time, so that we can do meaningful comparisons to past projects.  The best example of past experience would be comparing estimates to actuals on a project and comparing an upcoming release to a past release.  Generally those kinds of statistics are not captured in a meaningful fashion, although modern Application Lifecycle Management and Agile Software Development tools and techniques are changing that for the positive.

As we start to embrace more and better statistics in software architecture, we need to keep in mind that software architecture is still a very human process.  Statistics can help us judge our actions and make meaningful decisions, but the statistics cannot become the outcome of the process. 

“If you dwell on statistics, you get shortsighted. If you aim for consistency, the numbers will be there at the end.” – Tom Seaver

Architecture by Baseball: Jargon

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

Baseball Jargon

Last Saturday I watched a baseball game between the Milwaukee Brewers and the Cincinnati Reds.  I noticed that the announcers used a lot of colorful jargon in describing the action that was playing out on the field.  Baseball has built up an interesting language of its own over the years.  Some of my favorites are:

Ducks on the Pond – a term used to describe when there are runners on base, but usually stated when the bases are loaded.

Can of Corn – a term used to describe a pop-up or a fly out that is easily caught by an outfielder.  The term comes from a device that grocers used to grab canned goods that were located on top shelves in their stores.  This device allowed them to quickly and easily grab these cans, without having to stretch or get a ladder.  Of course the term does not translate to modern grocery stores.

Payoff Pitch – a term used to describe a pitch thrown with a full count (3 balls and 2 strikes).  The term is usually used when there are 2 outs or when the pitch could have a large outcome on the game (like bases loaded).  A strikeout could get the pitcher out of the tight situation; a hit could lose the game for him.

Murderer’s Row – A reference to the 1927 New York Yankees, who had several of the game’s best hitters in their lineup.  In later years, it has been applied to other teams who had similar lineups stacked with great batters.

No-no – a term used to describe a no-hitter.  This is a reference to the scorecard: No runs, no hits.  The no-hitter is one of the best accomplishments a pitcher can achieve (the record for career no-hitters is currently 7 over a 27 year career).  The no-no is only over-shadowed by a perfect game, which does not have a cool jargon associated with it.

Jam – a term with several meanings (you see this a lot in baseball Jargon).  It can mean a pitch that is far enough inside that the batter cannot get a full swing.  It can also mean when a situation where the pitcher is in trouble ala “Smith is in a jam”, generally there are runners in scoring position with less than 2 outs.  And finally it can mean when the baseball are loaded (but sometimes the bases are juiced instead of jammed – another term that can mean the same thing).

What I found really interesting is that none of these terms are actually defined anywhere in the official baseball rules.  If you were a new fan, you would have to pick up these terms by asking people when they meant, or by listening to the announcers and inferring what the term meant by looking at the situation.  You would doubtless be confused by the overloading of terms like Jam and by having more than one term applied to the same situation:  Bases can be jammed, juiced and ducks on the pond all at the same time. 

Architecture Jargon

In software architecture we have our own jargon as well – lots of it!  Some days it seems that there are teams of people sitting in a room creating more jargon.  A couple of my favorites are:

Polymorphic – an OO Concept (OO is another Jargon) that allows the use an operator or function in different ways for different set of inputs given.  I will never forget someone telling me, “I had to re-work the code to make it more polymorphic”.  I had no idea what he did to make it more polymorphic, but he seemed happy about it.

Service(s) – As an industry we have become service happy, but without a good definition of what a service is.  Most commonly when people say “service” they assume that you mean a SOAP based web service that uses XML serialization and http as a transport, as opposed to something more abstract.  Because the terms are so overloaded, you should always ask “What do you mean by service?”.

Separation of Concerns – architecting and implementing your software in such a way that there is little to no overlap in functionality.  Back in the day we used to just call that “good code”.

MVC, COM, SOA, etc – There are a veritable soup of Three Letter Acronyms (TLAs) that we use and reuse in discussions.  There are literally too many to keep track of.

As an architect, we are invested in this jargon and surrounded by it on a day to day basis, so much so that it actually becomes part of our natural language.  But the obvious thing to point out is that many people that we will work with are not software architects and may not even be in technology at all.  Note:  If you are a software architect who works in industry and you don’t spend time with non-technology folks, you are doing something wrong.

As software architects we have to be cognizant of the fact that our business partners and customers do not speak the same language as we do.  We also have to change our behavior to account for this.  Here are some of the things that I have seen successful to bridge this language gap:

Make it about the business and not the technology – when you are having a conversation with your business partners and customers you should not be focused on the technology, but on what the business outcome will be.  There are exceptions to this of course:  Occasionally there are technologies that your business asks for by name like AJAX as in “We need to get some AJAX in our websites now”.

Don’t use the Jargon – Avoid the 3 letter acronyms and words like polymorphism.  They are necessary to deliver the software, but not to understand what the software does.

When Jargon slips out, explain it – If you are in a meeting and you hear SOA, just pause for a second and explain that “SOA is Service Oriented Architecture and it is a technique for building the application that makes it easier for other companies to use our software and hopefully makes it easier to maintain”.  Be careful to not be condescending or over promise what the technology can do.

Architecture By Baseball: The Managers

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

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.