There's No Should in Software!

(Originally posted in 2016)

Hello, and welcome to the inaugural post to my blog, “There’s No Should in Software”!!

Given that the name of my blog isn’t something simple, like “Joe’s Blog” or “Blotner’s Blotter”, I thought the best choice for a first post would be an explanation of the title.

As any software engineer or leader knows (especially one who works on agile teams, as I have for 15 years) teams are always developing working agreements – those rules everyone agrees to live by.  As a leader/manager type, I try to be the author of VERY FEW of those rules, so the team is deciding for themselves how they want to operate.  Even so, though, I have a few rules that I have come to NEED in order to enable me to be the (mostly) hands-off leader that my teams need me to be.  Some such requirements have come and gone over the years, but there are a few that have stood the test of time (so far).  Today, I want to talk about this one:

Don’t should all over me or each other — strike the word “should” from your work vocabulary

Here’s why I hate that word so very much  — when the word “should” is in a sentence, there is simply no accountability for accuracy or truth on the part of the speaker OR the listener.  Think about it — how many times has someone said to you, “You can’t find it?  That’s weird.  It should be there!”  or “It should work now” or “The project should just roll smoothly after such-and-such happens.” or “Should we get approval for this”?   (This is where you pause and think about when you have heard these phrases….. okay, now read on)

I know, right?  When you stop to think about it, you realize it happens all the time!  It *sounds* good, but there’s no accountability, and you can end up with needless conflict….

So that’s why I eschew the word “should”.  Now, here’s the story about how I came by this aversion….

In 2007, I was managing the Global Tax Software team and a global online retailer headquartered in Seattle.  At the time, the company was moving to a more service-oriented architecture.  One such service was called the Order Calculation Service (OCS) and was owned by my office mate, who we’ll call “Bill” (because, well, that’s his name). OCS made a service call out to another service to acquire the product tax codes for the order, and passed them to my Tax service.  Both of our teams believed that the right place for that extra service call was in the Tax service.   After going over the technical details with Bill in our office — and I remember this very clearly — I said, “It should just work, right?”  And Bill said, “Yeah, it definitely should.  If you guys need any help, just let my guys know and they’ll come right over to help.” 

A week or so later, after doing all the right things — pairing, unit testing, integration testing extensively — we launched the updated tax service.  As with all deployments for the U.S. checkout pipeline, we deployed at 11:00pm, and all looked well in the tax service for the first hour after deployment.  We all went to sleep.

The next morning (a Saturday (yes, I know, but that’s a post for a different day)), our on-call engineer was awakened by a sev-2 ticket escalation — latency in the US checkout pipeline had spiked and all data pointed to OCS, whose metrics, in turn, pointed to the tax service.  We all got on the conference call (me from my car after dropping my daughter at Gymboree), and after a small amount of digging we saw that our latency had gone up since the deployment, but only by about 100ms.  This made sense, because we added that one service call (which we knew was about 100ms), but what didn’t make sense was that this one API call could cause the 300ms spike in order calculation latency.  We quickly rolled back the deployment (you don’t take too long to screw around when customers are trying to buy stuff!), and latency returned to normal. 

Upon further digging, it turned out that Bill’s service called my service multiple times, so his service cached the product tax code once, and passed it along on subsequent calls.  My service was stateless, which meant it had to make that service call EACH and EVERY TIME it was called by OCS.  So instead of Bill’s service making one 100ms call and passing me the data multiple times, my service was now making three or four 100ms calls (one for each time Bill’s service called us).  Voila!! We can now account for the 300ms latency spike!

As you might imagine, I said to Bill, “Bill, that was a surprise.  Why did you say that this should work?”  Bill’s response was that, from what he recalled of the code at the time, he saw no reason why it wouldn’t work; and, since my team was going to be working in the code, he expected that we would find and surface any problems that arose.  I told him I expected more knowledge from him about his software before he asserts something will work.  He responded — and rightfully so — “I didn’t say it will work, I said it should work”.

And there it was.  Bill and I stopped our conversation dead (which was pretty impressive, given how much each of us liked to talk).  We went to lunch that day and talked about the philosophy of “should”.  The thing we realized was this: the word “should” is usually shorthand for some form of uncertainty, or a way to suggest an action without explicitly instructing, asking, or volunteering.  “It should be there” really means “Last time I saw it, it was there; it’s been a couple weeks, though, so I can’t know for sure.”  Imagine how the cartoon above would have been different if the word “should” was not used.

Bill and I agreed that the better thing for me to have said was, “Let’s have our developers go through the OCS code together to look for any gotchas before we start this work,” and a better thing for Bill to have said would have been, “Yeah, that all makes sense logically.  There may be some gotchas there that I’m not thinking of right now, though.  Let’s have our developers go through…”; and we resolved to do so in the future. 

The next morning, I brought in an empty jar with a slot cut in the lid, and called it “The Should Jar”.  At stand-up, I announced that we are striking the word “should” from our work vocabulary, and that each time one of us says that word, he or she must put a quarter in the jar.  In the first week, we tallied up about twenty bucks, and I had to give everyone raises just so they could afford to speak.  (just kidding) 

Seriously, though, this transition was hard, and it’s been hard for each and every one of my teams in the nine years since then.  But, each and every team has found that the forcing of clarity in communication has been awesome.  They do more due diligence than they have before, and feel more confident in what they say.  And, they trust what others are saying more when they don’t get “should on” by people.  When someone puts “should” in an email, I often respond with something like, ” ‘Should’?  What’s your uncertainty?  What do you need to do to get from ‘should’ to ‘will’ or ‘will not’?”  The answers to such probing usually lead to very helpful information.

So, with my inaugural post, I offer you an explanation of the blog’s title and a recommendation to think about how this little word is working in your own workplace.  I hope this post was a little amusing, spoke a little to your own experiences, and was maybe a little enlightening.  That’s the goal of this blog. I would love any feedback or related anecdotes you may want to share.

Thanks for taking the time to read me,

Joe

P.S., I also offer one more piece of unsolicited, but very critical, advice around striking this word from the lexicon.  Do *not* try this at home with your spouse. Trust me. 

P.P.S., My thanks to Chris and Suzie for their editing help, and Kevin for his artwork!