Noel Rappin Writes Here

Strained Sports Metaphor About Process

Posted on June 4, 2010

Warning: Strained Metaphor Approaching

If there’s one thing about software development that has been hammered into my skull the last few months, it’s the idea that the details of your development process are less important than the mere idea that you have a process.

The goal is to get all your stakeholders to accept the idea that, unless the server is actually on fire, the process is more important to future success than any one individual feature, bug, or change. The exact way you monitor your backlog, or bugs, or stories is a detail. Getting everybody on your team to know that buttonholing developers in the hallway is not the way things get done is huge change.

Here’s the Strained Metaphor

On Tuesday, Detroit Tigers pitcher Armando Galarraga lost a perfect game with two outs in the ninth inning when the first base umpire clearly blew a call on a play at first. What’s striking about this to me is how many baseball fans who I expected would know better have been calling for Major League Baseball to override the call and declare Galarraga as having the perfect game he clearly earned.

There’s a reason, though, why sports leagues are very reluctant to overturn judgment calls made by the on-site judgment callers, whether they are umpires, referees, replay officials, or judges. It’s a matter of process. The idea that the umpire is the final word is more important than any single call – even a botched call like this. This is not a claim about the charm of the human element in baseball – everybody would be better off if the umpire had gotten the call right. It is a claim that once the call is made, it’s made.

It’s the same reason why umpires don’t change calls when managers argue. Even if the manager is right, once the idea is placed that immediate change is possible, the requests never end. It’s satisfying to think that overturning the umpires call would be a great idea for Galarraga, but it opens the door for this kind discussion to happen over and over, potentially undermining umpires on the field. Again, no great love for umpires, and I wish the call had been right, but even flawed umpires keep the game moving in the right direction.

Strained Metaphor Callback

It’s tempting to grab the nearest developer and just point them at a task without filing a bug or using the story software or setting priority at a meeting. It’s satisfying, too, if you’re into the snap-your-fingers-and-watch-them-jump school of dealing with personnel. But going around the process like this has costs. The developer has to drop something they were in the middle of. Without tracking, the people who test or accept the software won’t know how to evaluate the work. Whoever is in charge of keeping developers on-task has less knowledge of what the team is actually doing, or what their velocity really is. Without going through some kind of priority check, there’s no way to determine if the task you are throwing at the developer is really the highest priority thing they could be working on.

This isn’t an argument that you need a lot of process, or that your process needs to be perfect. It’s not even a claim that changes can never happen – of course you need a way to handle changes. It is a claim that once the process is in place, breaking it has negative effects that can linger beyond the immediate issue. Once you make it apparent that grabbing developers at whim is a thing you can do, it becomes easier for that to happen in the future, and then it becomes harder to plan and develop in the project over time.

(Footnote for the two baseball fans that would care: the George Brett Pine Tar game is different in that the umpire was incorrect about the rules, not that the umpire blew a judgment call. Still, I don’t think the league should have intervened there, either.)


comments powered by Disqus

Copyright 2024 Noel Rappin

All opinions and thoughts expressed or shared in this article or post are my own and are independent of and should not be attributed to my current employer, Chime Financial, Inc., or its subsidiaries.