Just Like…

 “I tried to explain as much as I could,” Poppet says. “I think I made an analogy about cake.”
“Well, that must have worked,” Widget says. “Who doesn’t like a good cake analogy?”

— Erin Morgenstern (The Night Circus)

 The Power of Analogy

Sometimes in software, because it is an ethereal product – we can’t really touch and taste our code or the architectural formations in our software – it is hard to make common-sense decisions about it, even though really smart people are involved.

To combat this challenge, I frequently resort to analogy (as anyone who knows me can attest). “It’s like…” is the start of many of my statements. I have found that relating a situation about software to something more familiar and tangible can help clarify thinking. My favorite analogies generally involve two different disciplines: manufacturing and sports. Why?

The process of manufacturing physical goods is surprisingly similar to the process of creating software – in fact, many of the learnings from manufacturing (e.g., Lean methodology) have been subsequently applied to the “manufacturing” of software with great success [1]. I also spent about 9 years of my early career building software for manufacturing companies, so it helps that I have familiarity with that industry as well [2].

Why sports? First off, many of us follow sports of some kind or have played them. But more importantly, most team sports have a very simple objective – often it is “score more points than the other team”. The structure of a sports team is similar to that of a software team: you have the players, who do the actual “work”; you have a coach or manager, who doesn’t actually do the work, but guides those that do [3]. And you usually have a General Manager, who is more concerned with longer-term direction, while keeping an eye on current wins and losses.

As well, professional sports have a tremendous amount of money involved to achieve this simple objective and, therefore, have become very efficient over time. By the way, the objective of professional sports teams also overlaps with that of software companies: they need to increase shareholder value. A quick look at the top 10 most valuable sports franchises [4] suggests that winning and franchise value are closely tied together, in the same way that value delivered through software and company value are.

An Example…

Let me take you through an example of one of my analogies. One day, I asked my head of QA a simple, but terrifyingly complex question: What defines quality for our product? Given that we were making enterprise software that was integrated into a complex IT ecosystem by various consultants and vendors, the QA leader was mystified by my question and struggled to come up with a cohesive answer. He threw out some hopeful guesses such as “minimize the number of defects” and “a low number of customer escalations”. After a few other random stabs, I felt sorry for him and, knowing that the world of enterprise software is complex, I chose to simplify the discussion by going to one of my “go to” [5] topics: Manufacturing.

I had just purchased a new tennis racquet for my son the previous day, so I asked my colleague, “What if we made tennis racquets? What would define quality for that business?” [6]. After getting a blank stare for a few moments, I asked further: “Is the quality of paint on the racquet important? Is the centering of the logo on the bottom of the shaft important?” More blank staring. “Is the tightness of the strings important?” I asked.

“I..I don’t know…I don’t know much about tennis racquets,” he finally blurted out. “That’s fine”, I said. “Let’s assume that we have no idea how tennis racquets are used – how would we find out?”

“I guess by asking Customers…,” said the exasperated QA manager. Game, set, match! This was the answer I was looking for. If we don’t know how the tennis racquet is used, we don’t understand quality [7]. The answer is to find people who play tennis (ideally professionals if that’s who we’re building the racquet for) and find out how they use it. Have them suggest quality criteria and, later, test your racquets.

The tennis racquet is easier to understand because it’s a physical item (much simpler than enterprise software), but the essence of quality isn’t any different. Through this analogy, the QA leader and I decided to survey the Customers to see how they were using our software. And “Customers” was broadened to include not just the company paying the license to our software, but the Systems Integrators, end users, IT staff and others, all of whom had interactions with our software where quality would be assessed. Once we created a prioritized list of what’s important to them, we could start building a picture of quality.

I have used various other physical items for the same discussion – usually whatever is in front of me – a pen, a water bottle or whatever I can grab. Next time you’re struggling to explain something complex, try out this same trick and let me know what kind of mileage you get.

This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker

Footnotes:

[1] One of my favorite books on Software Development, The Phoenix Project by Gene Kim et al (link) draws on the work of Eli Goldratt, one of the first academics to tackle the process of manufacturing in a scientific way. Goldratt’s book, The Goal (link), is the seminal book in this area and is the only book I remember being given by my father (which seems odd unless you know that my father has a Ph.D. in Engineering, specializing in Operations Research). As for Gene Kim, I saw him speak at a conference and he blew me away so completely that I went back to the office and immediately started enacting massive changes to how we delivered software.

[2] In particular, my cornerstone customer over that period was Procter & Gamble (In this blog, I will almost never name one of my customers nor employers directly. However, I feel comfortable naming P&G directly since it’s going back 20 years and I have nothing but glowing – and non-confidential – things to say about them). P&G was the most innovative North American manufacturer during that time (and I expect that they still are today). Through building software for them, I learned invaluable lessons about Continuous Improvement, as well as the specific sequence of improvement, which is to gather real data, determine root causes and eliminate waste starting with the most wasteful cause. By good fortune, some of the early software we created for a local P&G plant ended up making that plant massively better and their process was copied by many other plants. This allowed us to grow the business and travel all over North America installing our software. It was a provable fact that, at one point, everything I owned I owed to this good fortune and to P&G. To this day, as a symbol of my gratitude, I still religiously use P&G products. Not surprisingly, loyalty is one of the traits I value most in others.

[3] Usually based on having been a player themselves and, like software managers, this helps them in their coaching efforts, even if they weren’t the best player in their time.

[4] Forbes list of the most valuable sports franchises: link

[5] Note about unconditional branches – [Nerd alert: please ignore if you’re not an Engineer] Despite this being the second time that I have used the words “Go” and “To” in sequence in this blog, I am aware that unconditional branches are bad form in software. In first year university, we learned Edsger W. Dijkstra’s proof that unconditional branches were unnecessary to a programming language.

[6] As an aside, technically, this combines sports and manufacturing 🙂

[7] Similar to one of my favorite quotes about quality and customer-focus: “If you don’t know who your customer is you don’t know what quality is” by Eric Ries (the author of another one of my favorite books, The Lean Startup – link).