Mike Bland

This eighteenth post in the Making Software Quality Visible series covers the next entire section of the talk—it’s brief, but critical. We’ll define internal software quality and explain why it’s just as essential as external.

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.

What about the guitar stuff?

At the end of my previous post, I said I’d continue the series in a couple of weeks. I also said that I might post about some guitar hacking that I’d been doing lately. As it turns out, I was more burned out on blogging than I thought—which is why it’s been over three weeks now.

I’m happy to say my guitar hacking turned out nicely. I bought two suprisingly cheap and nearly identical electric guitars and performed identical upgrades on them:

• Kramer Baretta Special White
• Kramer Baretta Special Candy Blue

Both guitars now play like they’re worth at least four times what I paid for them. (They already sounded pretty good to begin with.) However, I ended up with more to explain than I anticipated, so it’ll take a while before I’ve finished that post. (Or maybe I should serialize that one, too…)

Moving on…let’s pick up right after Vital Signs Reveal the Matrix.

Is High Quality Software Worth the Cost?

martinfowler.com/articles/is-quality-worth-cost.html

To advocate effectively for an investment in software quality, we need to define clearly what it is and why it’s so important.

In May 2019, Martin Fowler published “Is High Quality Software Worth the Cost?,” a brief article describing the tradeoffs and benefits of software quality.

He distinguished between:

• External quality, which obviously makes users happy. This, in turn, keeps developers productive, since they don’t need to respond to problems reported by users. Then Martin argues that…

• Internal quality helps keep users happy, by enabling developers to evolve the software easily and to resolve problems quickly. This is because high internal quality makes developers productive, since there’s less cruft and unnecessary complexity slowing them down from making changes.

Effects of quality on productivity over time

Martin also used this hypothetical graph, based on his experience, to illustrate the impact of quality tradeoffs over time.

• With Low internal quality, progress is faster at the beginning, but begins to flatten out quickly.

• With High internal quality, progress is slower at the beginning, but the investment pays off in greater productivity over time.

• The break even point between the two approaches arrives within weeks, not months.

• Though Martin’s original graph didn’t show this, the difference in productivity between low and high internal quality is one way to visualize technical debt.¹

“Fast, cheap, or good: pick two three”

High quality software is cheaper to produce

Martin’s conclusion is that higher quality makes software cheaper to produce in the long run—that the “cost” of high quality software is negative. “Fast, cheap, or good: pick two” doesn’t hold as the system evolves. It may make sense at first to sacrifice good to get a cheaper product to market quickly. But over time, investing in “good” is necessary to continue delivering a product quickly and at a competitive cost.

Internal quality aids understanding

High quality software is cheaper because it’s easier to work with

Internal quality essentially helps developers continue to understand the system as it changes over time:

• Fosters productivity due to the clarity of the impact of changes
  When they clearly understand the impact of their changes, they can maintain a rapid, productive pace.

• Prevents foreseeable issues, limits recovery time from others
  Understanding helps them prevent many foreseeable issues, and resolve any bugs quickly and effectively.

• Provides a buffer for the unexpected, guards against cascading failures
  These qualities help create a buffer for handling unexpected events,² while also guarding against cascading failures.

• Your Admins/SREs will thank you! It helps them resolve prod issues faster.
  Your system administrators or SREs will be very grateful for building such resilience into your system, as it helps their response times as well.

• Counterexamples: Global supply chain shocks; Southwest Airlines snafu
  For counterexamples, recall the global supply chain shocks resulting from the COVID-19 pandemic, or the December 2022 Southwest Airlines snafu. These systems worked very efficiently in the midst of normal operating conditions. However, their intolerance for deviations from those conditions rendered them vulnerable to cascading failures.

• Quality, clarity, resilience are essential requirements of prod systems
  Consequently, internal software quality, and the clarity and resilience it enables, are essential requirements of any production software system.

(The following paragraph appears as a footnote in the original.)

In my talk Automated Testing—Why Bother?, I go into several more reasons why automated testing helps developers understand the system, particularly when responding to failures. These include better managing the focusing illusion, the Zeigarnik effect, the orienting response, and the OODA Loop. I learned about all of these except for the OODA Loop from Dr. Robert Cialdini’s Pre-Suasion: A Revolutionary Way to Influence and Persuade.

Focusing on internal software quality is good for business…because it’s the right thing to do.

As mentioned, Martin Fowler’s argument is that internal software quality is good for business—it’s such a compelling argument that I brought it up first. However, he prefers making only this economic argument for quality. He asserts that appeals to professionalism are moralistic and doomed, as they imply that quality comes at a cost.

I disagree that we should sidestep appeals to professionalism entirely, and that they’re incompatible with the economic argument. I think it’s worth exploring why professionalism matters, both because it is moral and because customers increasingly expect high quality software they can trust.

Quality without function is useless—but function without quality is dangerous.

Put more bluntly, high quality may be useless without sufficient functionality, but as we’ll see, functionality without quality can be dangerous. Professionalism and morals only appear to come at a cost today. They’re actually investments that avoid more devastating future costs when a lack of focus on quality begins to impact users.

Remember the examples of unit testable bugs I described from my personal experience.

• Byte padding: USCG/USN Navigation
  A byte padding mistake could’ve caused US Coast Guard and US Navy vessels to crash.
• Goto Fail: macOS/iOS Security
  An extra goto statement endangered secure communications on billions of devices.
• Heartbleed: Secure Sockets Layer
  Unchecked user input compromised secure sockets on the internet for years.

I caught the first bug, fortunately; but in the last two cases, a lack of internal quality and automated testing put many people at risk.

The point is that…

Quality Culture is ultimately Safety Culture

…a culture that values and invests in software quality is a Safety Culture. Society’s dependence on software to automate critical functions is only increasing. It’s our duty to uphold that public trust by cultivating a quality culture.

It’s ultimately what’s best for business and our own personal success as well.

Users don’t care about your profits.
They care if they can trust your product.

Users are the source of your profits, but they don’t care about your profits or your stock price. They care whether or not they can trust your product.

Appeals to economic self-interest vs. appeals to professionalism

(This section appears as a footnote in the original.)

I’ve more thoughts on Martin’s assertion that appeals to professionalism are moralistic and doomed. This seems somewhat ironic, since he invited me to publish Goto Fail, Heartbleed, and Unit Testing Culture on his website in 2014. It doesn’t focus only on the professionalism angle, but it emphasizes it heavily. He published the “Cost” article in 2019, reflecting an apparent evolution in his thinking.

I’m not criticizing Martin, or his argument—I’m rather grateful he came up with this brilliant angle, and explained it so thoughtfully and clearly. It’s incredibly helpful to move the conversation forward. I’m just not willing to abandon the “moralistic” appeal to professionalism, either. We need both.

In fact, I’d claim that a sense of professionalism necessarily precedes sound economic arguments in general. Raw economics doesn’t care about professionalism, but pragmatic professionals have to find a way to align the economics with their professional standards. That’s exactly what Martin did with this article.

Also, though he didn’t explicitly state this, it’s possible he meant “professionalism” in terms of “quality for its own sake” or “pride in one’s work.” Whereas the angle in my article, and in the slides to follow, is “professionalism” in terms of social responsibility, which also has an economic impact. I do believe in quality for its own sake and having pride in one’s work, but that’s not the appeal I tend to make, either.

All of this said, Robert Greene’s The 48 Laws of Power advises (emphasis mine):

Law 13: When asking for help, appeal to people’s self-interest, never to their mercy or gratitude

Though that title speaks specifically about gaining someone’s favor, the general principle of appealing to someone’s self interest to motivate their behaviors holds. That said, in the “Reversal” section at the end of the chapter on Law 13 states:

You must distinguish the differences among powerful people and figure out what makes them tick. When they ooze greed, do not appeal to their charity. When they want to look charitable and noble, do not appeal to their greed.

My interpretation of this principle in this context is: Don’t go all in on either the economic argument or appeals to professionalism. Use both, and presented well, I think they serve to reinforce one another.

So while I understand why Martin has taken the position he has, I’m slightly saddened by it. Or, if he’s responding to certain aspects of professionalism without distinguishing from the others, I’m only sad that he was uncharacteristically unclear on that point. Morals aren’t the only concern, but neither should economics be—alignment between them, rather than abandonment of one for the other, yields the best outcomes.

Coming up next

The next post in Making Software Quality Visible series will introduce the next major section, Why Software Quality Is Often Unappreciated and Sacrificed. We’ll examine several psychological and cultural factors that are detrimental to software quality.

• Why Software Quality Is Often Unappreciated and Sacrificed

Or maybe I’ll write about my Kramer Baretta Special hacks first. We’ll see.

Footnotes