There's No Should in Software!

A few years ago, I was fortunate enough to attend a workshop that was co-led by an olympic champion. I was incredibly excited when she walked in the room. I don’t watch much volleyball regularly, but my wife and I are Olympics junkies, and I remembered her and her team’s run to the gold. In the opening session, this athlete told compelling behind-the-scenes stories about her experiences on Team USA, focusing on the work, preparation, and team building required to eventually stand on the Olympic podium. I could have listened to her all day.

In fact, many elite athletes go on to have lucrative careers as career coaches and motivational speakers once they retire from their chosen sport.  Becoming an elite athlete requires fierce dedication and sacrifice from childhood, but the whole shebang is usually over by the time they reach age 30, and many, many athletes have suffered from being ill-prepared for the next 50 years of their lives. I love that so many of these individuals have found a way to leverage their lifelong sacrifice, dedication, and learning to make a living by helping others.  

Having said that, we on the receiving end of that coaching need to recognize that these lessons aren’t completely transferable to our work lives. Both sports and business have the notions of strategies, tactics, and teams, but that’s pretty much where the similarities end. 

We need to stop using sports as a metaphor for business. 

I was an athlete in my youth and am still a big sports fan.  In spite of that – or maybe because of it – it’s clear to me that believing our work teams will be successful if we only emulate sports teams is a fallacy, really.  Here’s why:

• In sports, you face one competitor at a time (maybe a few, as in gymnastics or track and field), and you do so face to face, pitting your best effort and skill against their best effort and skill on a predetermined competition day. In business, you compete against all the competitors all the time, and it’s almost never face-to-face. You rarely get to watch them display their talent and skill. 
• In sports, there is a clear beginning and end of the match / game / meet where you compete with your opponent, and when it’s over in a few hours (or days, for Cricket), there’s a clear result – win, loss, draw. In business, these moments rarely exist (if ever) the start and end times are nebulous, and the results are rarely clear.
• When you’ve beaten a given competitor once in sports, that’s it and you move on to the next.  In business, you need to beat them over and over and over again.  You don’t know who all your opponents are, and they don’t start the game at the same time.  In fact, they aren’t always even playing the same game!
• In sports, you prepare to compete against a specific opponent, you compete against that opponent, and then you recover and start to prepare for the next opponent.  In business, you compete every single day against every opponent, and there’s no cycle of prepare / compete / recover.  It’s prepare / compete (often at the same time). And because you don’t always know who your opponents are, you can’t prepare specifically for them.
• In sports, the only thing you need to be victorious is to perform better than your opponent on competition day, and usually there are 3rd parties (the audience) who care, but don’t have an impact on the outcome. You don’t need to always be better than them – just bring your best work the day you face them, and stop them from doing their best. In business, there are myriad outside forces that can impact your path to victory, and there’s a third party (the customer) who doesn’t give two figs about the competition you’re in, because they need to win the game they’re playing.
• In sports, there are established rules, competitions are overseen – live – by sanctioned officials, and there are penalties for breaking those rules.  In business, there are laws and regulations, but very little live oversight and penalties, and penalizing a rule-breaker must be done by you, and can be very expensive.
• In sports, it’s accepted that many people will try out for the team, be assessed for their ability, and potentially told they aren’t good enough.  And, for those who make the cut, they know that if their performance doesn’t stay at a high level, they could lose their position with no notice.  In business, we interview people for a few hours (see my post on interviewing) and hope they’re good at the job; and if their performance isn’t up to par, there is a long, intensive process to manage them out.
• And, maybe most importantly: sports have seasons and off-seasons; there is no off-season in business. Elite athletes sacrifice family and work/life balance during the season, because they know they can have full family and rest time in the off-season. In business, we see major burn-out, destroyed relationships, and other detritus if we don’t manage our work-life balance all year long.

It’s not that the lessons from sports can’t be applied to business.  It’s just that the parallels aren’t as great as they may seem in the middle of the insular experience of the workshop. We on the receiving end need to put the workshop lessons through a filter of practicality.  

While there are many differences between sports and business, I cannot let this post end without reminding all of us that there is one important similarity.  Not everyone has equal access to the resources and forums to play sports, just as not everyone has equal access to the resources and forums to participate in business. I heard the following phrase a number of years ago, and it resonated deeply with me:

Talent is equally distributed, opportunity is not.

I fully recognize the privilege that my personal heritage and visage offer me. Access, affordability and bias are huge barriers to a level playing field, both within and outside of sports. As a result, we have lost generations of genius in so many areas of our world, and millions of highly qualified people have been unable to realize their potential and dreams. The work must continue, and accelerate, to avoid propagating this tragedy. 

Obviously, there are many lessons we can take from sports and apply to our work lives – providing opportunities for all players, being a supportive and productive teammate, preparing, giving our all. But it’s not all applicable. Business is more complex and ambiguous, and the landscape and rules are constantly changing.  We must remember the key differences and not blindly try to turn our offices into hyper-intense Olympic stadia.

or, Can’t Help Lovin’ that Tool of Mine

Imagine you are awesome at mazes and find yourself in a hedgerow maze with clues along the way that help you get out.

You’re moving along, piecing things together to get through the maze, when suddenly your foot gets caught under some root.  You have to stop thinking about the clues and extricate yourself.  You deal with the root, and now, you recall the clues you had before, reconstruct your strategy and move forward three steps, only to have some dude step out of a hedge and block your path.  Now, you need to stash away the clues in your memory and deal with this guy.  Okay, so you’re done with him, you get your head back in maze-solving mode, go around a couple turns, get your momentum going — and around a turn, part of the hedge is on fire.  Great.  Okay, stop maze-solving and figure out how to get around the fire safely. You can’t figure it out, so you call a friend; she tells you the undocumented way to get past the fire and you do; you then let your adrenaline level off and try to remember all the clues and get back into maze-solving mode.  Your foot gets caught in another root; how did you solve that root problem before?  Oh, yeah.  Okay, solved quickly.  Back to maze-management…

Four hours have passed and you’ve gone about 30 feet. 

I have always heard developers I’ve worked with express their passion about the tools they are and aren’t using, and training that they are or aren’t getting.  And as a two-decade-tenured leader in software engineering, I have received innumerable requests for tools and training.  I have been sympathetic to these issues, and have always tried to get my people the tools and training they say they need to get their job done.  I have not, I must admit, often actively sought out what they needed to make their jobs better or make them more effective.  And, when a developer has said, “I’m making Tool X work for me; don’t worry about it”, I have been satisfied to let the status quo remain intact.  That changed for me a while back.

Back in 2017, I had the opportunity to step into a straight-up IC role at a new company (part of the rite of passage for taking on the manager job for which I was hired).  Not having coded with any regularity for about nine years, I had a variety of rust to shake off and a lot to learn.  Today, I am writing about the unexpected lesson I learned from that experience — any disconnect between the engineer and the tools he/she has to do the job will create impedance that is orders of magnitude worse than I ever thought. Note: I did not say “can create”; I said “will create”.   

To start me off, I was given a non-trivial, but reasonable first project (thanks, Russel!).  It was in a familiar language, the code was very clear and self-documenting, and there was already an architectural pattern established. What would take me 2-1/2 weeks to accomplish this task was setting up my machine, learning tools my teams had been using for some time (but I had never personally used) and learning “how we do things here”.  I probably spent a cumulative total of three days on solving the actual business problem, and the other ten figuring out how to test, build, test, code review, test, merge, test, deploy, test, and — the context switching in between. 

The company had a very good tool chain for developers (most of it commercial, some of it home-grown) and several teams actively working to continually improve it.  The issue for me was that I hadn’t used *any* tools in forever.  Now, in my case, the issue was that I was (as stated above) inexperienced, period.  But, still – there was a disconnect.

The major time sink wasn’t even the differential in time it took to solve the problem vs execute the solution — it was that I repeatedly had to interrupt my execution on the business problem with tool difficulties.  I would repeatedly get into flow for a couple hours and then hit some tool knowledge barrier that had to be overcome.  It was slow-going.  And, it was frustrating — I really wanted to solve this business problem, but I couldn’t get to it because I had to repeatedly context switch between solution mode and tool-learning mode. 

Again, In my case, the situation was that the tools are great, but the engineer (me) was inexperienced with them (I am happy to say that my second task, which was larger in scope, took about half the time 😃 ). But it illuminated something for that, when extrapolated out, showed me a problem that even the most experienced developers face.

The same experience is encountered by seasoned developers who are saddled with inferior, or lack of, tools and training.  They spend their time working through problems they shouldn’t have to tackle, and doing things that, frankly, we don’t interview them for (think about it – have you ever asked a developer to talk about getting her code into production?  I haven’t).

When this disconnect occurs, we must solve it, and fast.  The cost of NOT doing so is HUGE.

There is a mythology that pervades our industry — we think we can’t afford to take the time or spend the money on training and tools because it takes away from productivity.  The reality is that we can’t afford not to invest in this way, and that a lack of such investment is actually sabotaging the very productivity we claim to be preserving. 

If you don’t believe me, think about context switching and flow.  We all agree that context switching is expensive, right?  Joel Spolsky offers this very helpful explanation as to why:

The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code.

Reggie, one of the most insightful engineers I’ve ever worked with, would talk about how developers need time to be in flow.  It’s not about the cumulative hours spent coding, he explained, it’s about the contiguous time the brain could be in the problem and solution.

So, we try to minimize interruptions — we set up constructs like meeting-free days, on-call rotations, and blocked-out “work” hours; we try to minimize the number of meetings for our engineers, and allow them to work from home when they need to focus.  All agreed?  Good.

But these are only the external interruptions.  We are missing the internal interruptions – tool doesn’t work right, I have to work around a tool deficiency, I have to look up how-to articles to get this language / package / technology to do what I need.  These internal interruptions are as counter-productive as the external ones, and they can lead to greater frustration because they happen silently and thus with no decent outlet for that frustration energy.  Tools that work well and don’t interrupt flow, and training on the technology in use such that engineers are proficient in them, drastically improve productivity and job satisfaction.

The maze is in front of our people, and they have the skills and desire to get through it.  After this experience, I became committed to preventing the distractions that keep them from solving it.  Are you?

(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!