“Look who’s calling the cauldron black.”
“Kettle. It’s a kettle. Get your metaphors right.”
“That wasn’t a metaphor. It was a, you know…” He stared off into space, blinking. “One of those things that’s symbolic of another thing. But isn’t the same thing. Just like it.”
“You mean a metaphor?”
“No! It’s like a story…like…a proverb! That’s it.”
“I’m pretty sure that wasn’t a proverb. Maybe it was an analogy.”
“I don’t think so.”
— Richelle Mead (Succubus on Top)
In the previous post, I mentioned that I use analogies extensively and gave an example from one of my favorite domains – manufacturing. I realized that I short-changed the readers by not also delivering an analogy using my other predictable topic – sports. This post is an attempt to correct that.
Assessing whether actions are in line with Objectives
There are a lot of differing opinions in software development about what is important. To some, it is code quality [1]. Some people believe that process is king [2]. Others are interested in ensuring that Engineers are engaged. The list could go on infinitely and it’s hard to arbitrate amongst what is most important.
If you recall, as outlined in the Introductory Series, we established that the purpose of Engineering is to deliver as much valuable functionality to our Customer as possible. This (sort of) helps guide our decision about what is most important, but is (for example) clean code the most important mechanism to deliver valuable functionality? It can be hard to assess.
Here’s where I believe that a good analogy saves the day. Let’s start with imagining a sports team. Not knowing your favorite sport [3], I will let you imagine your own. And let’s assume that a group of people new to the sport observe the team playing one of their home games. One spectator comments that the hamburgers from the refreshment stand are undercooked. Another thinks the home team has no chance to win because their jerseys are dirty. Yet another is surprised that the stadium is so run down. Someone else notices that the away team’s equipment looks newer and shinier, so suggests that they will likely be victorious.
We can laugh at these neophytes, but you might be surprised at how often we do something similar in software development. In the case of the sports team, we know that their primary objective is to outscore the other team (and, in the longer term, win more than the other teams). We know that the cleanliness of uniforms or newness of the equipment is irrelevant.
But I can tell you from my experience and that of many others I have talked to, how often we spend time fretting about framework X over framework Y; Sprint tracking tool A over Sprint tracking tool B; code cleanliness; source control processes, etc. Many of these things are undoubtedly important, but the only thing that truly matters is delivering valuable functionality. If changing Sprint tracking tools or source control systems doesn’t make a material difference to that, we shouldn’t waste our time. We should spend that time instead on interactions with our Customers. The Blog Series Assessing Your Customer Focus can give you many ideas about how to do so.
On the topic of Clean Code, I am going to wade into some shark-infested waters here and suggest that the purists in this field can be a little like the spectators worrying about clean jerseys and new equipment. Now don’t get me wrong – hygiene on certain items in the sports world (such as water bottles and undergarments) is very important and has negative health consequences if ignored. I feel the same about code cleanliness. To a degree, and applied to the right areas, it is important for code health – we don’t want our code to itch. However, overapplied, it is a massive waste of time and energy at the expense of delivering that valuable functionality the Customers are waiting for.
I have had teams that debated endlessly over whether a “for”, “for-each” or “while” loop [4] was the right construct for a specific 10-line chunk of code. I have had Engineers incessantly deliberate the appropriate name for a variable [5]. In one particular team that spent the majority of their time on such pursuits, the code was used internally (i.e., not visible to our Customers) and wasn’t even contained in the finished product. To me, this is a little like worrying about a small stain on the inside label of your star player’s uniform pants. It’s a little hard to argue that the star’s scoring ability will be hampered by the stain.
I’ll say one more thing to the Clean Code acolytes – by me saying I’m not a strict disciple, it doesn’t mean that I advocate Dirty Code [6] any more than an equipment manager that doesn’t worry about meticulously clean uniforms is suggesting that they should be filthy. I have a Computer Science degree and if you could inspect all the code I ever checked in, I think you would find 90% of it was well thought out, well written and sufficiently documented. I expect the same of every Engineer that works with me. What I am saying is “Let’s not obsess over it”. Every time you get the urge to comment on someone’s code review, you need to think to yourself: “Will this result in more value to my end Customer?”
I hope this second analogy post was helpful and I look forward, as always, to your comments below.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] The notion of code quality, often known as the Clean Code movement, is the belief that very well-written (a.k.a. “Clean”) code is the cornerstone of good development.
[2] or queen
[3] I’m assuming that you have one; if not, pick one now – baseball and hockey are both good choices :).
[4] These are different keywords used by programmers to make their code loop through a list of “things” (e.g., all unpaid Invoices).
[5] A “variable” is a temporary storage place for some value we need in our programming logic (e.g., credit_limit might store the Customer’s current Credit Limit).
[6] This is what is referred to in analytic philosophy as the “false dichotomy fallacy”.
Leave a Reply