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