Mike Bland

This fifteenth post in the Making Software Quality Visible series explains why belief is the primary obstacle to replacing heroics with a positive Chain Reaction. The content of this post comes from footnotes to the portion of the original presentation covered in The Test Pyramid and the Chain Reaction.

I’ll update the full Making Software Quality Visible presentation as this series progresses. Feel free to send me feedback, thoughts, or questions via email or by posting them on the LinkedIn announcement corresponding to this post.

Continuing after Contract/Collaboration Tests and Internal APIs…

Knowledge, awareness, assumptions, and belief

Unit testing existed before the World Wide Web,¹ and the Test Pyramid has existed for years.² We organize individual lines of code via sequence, selection, iteration, functions, classes, modules, etc. At this molecular level, most code is essentially more alike than different. There are plenty of tools, frameworks, documentation, and working examples to help developers write their own automated tests. From this perspective, if one embraces the Quality Mindset, there is no code that’s “too hard to test,” modulo careful refactoring to make it testable.

This doesn’t mean that higher level, emergent properties of an application may prove complex and challenging to test, well beyond the scope of smaller tests. This is why we must spare human creativity and bandwidth for such challenges by automating as much lower level testing as possible.³

As for code that’s “too trivial to test,” anyone who’s spent significant time testing their own code doesn’t believe such code actually exists. Maybe early prototypes and very small, straightforward programs that stand alone and aren’t on the critical production path are safe to leave untested. Pure setters that only assign a value with no other logic, and pure getters that only return a value, aren’t worth testing specifically. Beyond that, those of us who test our own code regularly know from experience how often “trivial” code causes tests to fail. In fact, “trivial” code can be amongst the most dangerous to leave untested; it receives less scrutiny because we assume it just works. Add enough “trivial” needles to a haystack of untested code, and you’ll eventually end up with a stack of needles.

Consequently, in The Test Pyramid and the Chain Reaction, I asserted that:

The main obstacle to replacing heroics with a Chain Reaction isn’t technology, it’s an absence of awareness or belief that a better way exists. Despite the fact that many quality and testing problems have been solved for decades, many still haven’t seen those solutions, or seen them done well.

The good news is that these solutions can seem easy and obvious—after they’ve been clearly explained and demonstrated. So how do we get started showing people what the right way to improve software quality looks like?

(Hint: This is where the Test Pyramid and Vital Signs come in.)

“An absence of awareness [of] or belief [in]” these automated testing principles and practices is an impediment to positive change. This is a consequence of one of my favorite concepts from Saul Alinsky’s Rules for Radicals, which I paraphrased in Automated Testing—Why Bother?:

If people believe they lack the knowledge and power to solve a problem, they won’t even think of trying to solve it.

My claim was also inspired by Immunity to Change by Robert Kegan and Lisa Lahey—though I’ve yet to read the book. I learned about it from Harvard expert on the worst thing about New Year’s resolutions—and how to beat it: ‘A profound loss of energy’ (CNBC, 2022-12-31). That article quotes Lahey’s four step process to “breaking our resistance to change”:

1. Identify your actual improvement goal, and what you’d need to do differently to achieve it.
2. Look at your current behaviors that work against your goal.
3. Identify your hidden competing commitments.
4. Identify big assumptions about how the world works that drive your resistance to change.

Assumptions, until identified, are essentially unspoken or unconscious beliefs.

Time

The “Avoiding the trap of productivity theatre” section from the first post in this series references a New York Times interview with Cal Newport. In that same interview, The Digital Workplace Is Designed to Bring You Down, he makes another relevant observation germane to the topic of adoption:

“If we look through the history of the intersection of technology and commerce, we always see something similar, which is: When disruptive technology comes in, it takes a long time to figure out the best way to use it. There’s this case study⁵ from a Stanford economist about the introduction of the electric motor into the factory. He characterizes how long it takes before we figure out what was in hindsight the obvious way to use electric motors in factories, which was to put a small motor in every piece of equipment so I can control my equipment at exactly the level I want to use it. We didn’t do that for 20 or 30 years.”

⁵ Paul A. David’s “Computer and Dynamo: The Modern Productivity Paradox in a Not-Too-Distant Mirror,” published in 1989.

In other words, known solutions still take time to sink in and become so obvious and easy to use that they become common practice. So maybe we’re approaching the tipping point as I write this sentence (originally) on January 23, 2023, as unit testing is over 30 years old.

Wisdom

In Software at Scale 53 - Testing Culture with Mike Bland, I discuss with Utsav Shah why effective testing practices haven’t yet caught on everywhere. It seems part of the human condition is that wisdom passed down through the ages still requires that individuals seek it out. Good examples and teachers can help, but those aren’t always accessible to everyone, at least not without some self-motivated effort to find them.

By way of analogy, I mentioned just having read the Bhagavad Gita. In it, the warrior Arjuna struggles with the prospect of going to war against his own family. The supreme being, Krishna, then convinces him that doing so is his duty—which is quite shocking by today’s standards. However, read as only a metaphor for profound internal conflict and doubt that was accessible to the audience of the day, the message is reassuring. But it takes a willfully open mind to derive such value.

On top of that, one of the main lessons is that one should feel attached to doing one’s work—but not to the outcomes. This is a pretty common theme, also running through The Daily Stoic, which I’d also recently finished. Other traditions, notably Buddhism and Taoism, also teach detachment from outcomes and other things beyond one’s control generally.

However, despite this message being developed in multiple ancient cultures and spreading throughout history, tradition, and literature, people still struggle with attachment to this day. The essence of such wisdom isn’t necessarily complicated, but it’s often obscured by other natural preoccupations of both individuals and cultures.

This doesn’t contradict Cal Newport’s observation above on the time it takes for organizations to assimilate new technologies. It perhaps helps explain, at least in part, why it takes so long.

The Egg of Columbus

The Egg of Columbus parable is my favorite illustration of these principles.

As the story goes, when Columbus attended a party with Spanish noblemen after discovering the New World, they disparaged his accomplishment as obvious and inevitable. In response, Columbus challenged them to stand an egg on its end. When none of them could, he showed them how, by tapping and slightly breaking one end first.

The point is that some solutions only seem obvious, trivial, and inevitable after someone shows them to you—often directly to you, not related secondhand. Until then, it’s only natural to struggle with certain tasks and to believe them impossible.

Coming up next

The next post will pick up the main narrative again, explaining the common phenomenon of the “Inverted Test Pyramid” and all its familiar consequences.

• The Inverted Test Pyramid

After that, I’ll do a deep dive into the concept of “Vital Signs.”

• Vital Signs Reveal the Matrix

Footnotes