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.