Mike Bland

Back in February I announced my Making Software Quality Visible presentation, and mentioned that I planned to break individual posts out of it. (Then I got sidetracked by improving my blog’s appearance, and then by improving the appearance of email updates, and then by writing EListMan…) So this is the first post in what I expect to become a long series.

The intentions are:

• to publish more frequent, more substantial blog posts for as long as I can
• to start one small conversation at a time around each topic
• to motivate myself to complete some of the outstanding TODOs in the original presentation
• to integrate updates from recent versions into the main presentation
• to reflect upon and refine each individual piece over time, building a stronger presentation overall

I’ll probably still post other things over time, like my recent CSS, email, Go, and AWS learnings. All posts in this particular series, however, will have the Making Software Quality Visible tag.

Talk to me!

If you have thoughts you’d care to share, feel free to email me or post them on the LinkedIn announcement corresponding to this post. (That goes for all my blog posts, really.)

So here we go…

Software Quality must be visible to minimize suffering

I’m going to talk about how making software quality visible will minimize suffering.¹ By “suffering,” I mean: The common experience of software that’s painful—or even dangerous—to work on or to use.

By “software quality,” I mean: Confidence in the software’s behavior and user experience based on information and understanding. This is opposed to feeling anxious or overconfident about how the software will behave in the absence of information.

The way we produce accessible and useful information that enables understanding is by managing complexity effectively. If the information we need is obscured by complexity, we make bad assumptions and bad choices and suffer as a result. As we’ll see, software complexity is rooted not just in the code itself, but in our culture, which shapes our expectations, communications, and behaviors.²

Finally, by “making software quality visible,” I mean: Providing meaningful insight into quality outcomes and the work necessary to achieve them.

Quality work can be hard to see. It’s hard to value what can’t be seen—or to do much of anything about it.

This is important because it’s often difficult to show quality work, or its impact on processes or products. How do we show the value of avoiding problems that didn’t happen? This makes it difficult to prioritize or justify investments in quality, since people rarely value work or results they can’t see. Plus, people can’t effectively solve problems they can’t accurately sense or understand.

Avoiding the trap of productivity theatre

This section appears as a footnote in the original presentation, but I want to draw more attention to it here. I may do this for future footnotes as well, or even break some into their own blog posts.

David Marchese’s interview with Cal Newport for the New York Times on 2023-01-23, The Digital Workplace Is Designed to Bring You Down, bears mentioning here. Newport notes that with the rise of “knowledge work”, “we fell back to a proxy for productivity, which is visible activity.” Then:

“Visible activity as a proxy for productivity spiraled out of control and led to this culture of exhaustion, of I’m working all the time, I’m context shifting all over the place, most of my work feels performative, it’s not even that useful.”

He also noted Peter Drucker’s coining of the term “knowledge work” in 1959 and the consequences for management:

“So Drucker is saying that knowledge workers need to manage themselves. Managers just need to set them up to succeed. But then what do you manage? Visible activity as a proxy for productivity was the solution. We need something we can focus on day to day and feel that we’re having a role in pushing work: Let’s just manage visible activity. It’s this compromise that held the pieces together in an imperfect way, and then in the last 20 years, this centrifuge of digital-accelerated work blew it apart. The compromise is now failing.”

So there is a danger that trying to make work visible could dissolve into productivity theatre. At the same time, Newport unpacks his concept of “slow productivity,” the topic of his next book [emphasis mine]:

“So how do you actually work with your mind and create things of value? What I’ve identified is three principles: doing fewer things, working at a natural pace,⁹ but obsessing over quality. That trio of properties better hits the sweet spot of how we’re actually wired and produces valuable meaningful work, but it’s sustainable.”

⁹ Meaning one with more variability in intensity than the always-on pace to which we’ve become accustomed.

This presentation walks the line between making visible the aspects of our work that truly speak to software quality, and superficial displays of productivity. People often want to jump straight to solutions, and start generating performative “data” to prove their value. In doing so, they fail to grasp the underlying issues and end up continuing the negative cycle of increasing effort yielding decreasing quality.

We first need to help people get a handle on the issues and understand what we need to accomplish. This is why this talk makes the case for software quality and illustrates its obstacles before discussing solutions. It’s also why the solutions offered are rudimentary guidelines and techniques for inviting nuanced discussion and developing shared understanding that grows over time.

The punchline being, in the end, improving software quality is about leadership far more than it is about technology. Leadership requires helping people clearly see principles in action and getting results, so that they may learn from the example and achieve similar success. Hence, though making quality work visible may remain an imperfect practice involving trade-offs and compromises, it’s essential to improving software quality broadly across organizations.

Agenda

Here are the main topics I’ll cover throughout this series. This agenda may change somewhat as the series unfolds—and I may work in a technical example from EListMan—but here’s the plan for now (updated 2023-08-17):

• Formative Experiences at Northrop Grumman, Google, and Apple
  I’ll share examples of making quality work visible to minimize suffering from my experiences at Northrop Grumman, Google, and Apple.

• Skills Development, Alignment, and Visibility
  I’ll share some ideas for cultivating individual skill development, team and organizational alignment, and visibility of quality work and its results.

• The Test Pyramid and Vital Signs
  We’ll use the Test Pyramid model to specify the principles underlying a sound testing strategy. We’ll also discuss the negative effects that its opposite, the Inverted Test Pyramid, imposes upon its unwitting victims. I’ll then describe how to use “Vital Signs” to get a holistic view on software quality for a particular project.

• What Software Quality Is and Why It Matters
  We’ll define internal software quality and explain why it’s just as essential as external.

• Why Software Quality Is Often Unappreciated and Sacrificed
  We’ll examine several psychological and cultural factors that are detrimental to software quality.

• Building a Software Quality Culture
  We’ll learn how to integrate the Quality Mindset into organizational culture, through individual skill development, team alignment, and making quality work visible.

• Calls to Action
  We’ll finish with specific actions everyone can take to lead themselves and others towards making software quality work and its impact visible.

Coming up next

The next few posts will briefly summarize my formative experiences at Northrop Grumman, Google, and Apple, starting with:

• Formative Experiences at Northrop Grumman Mission Systems (begins the “Formative Experiences at Northrop Grumman, Google, and Apple” section)

I’ll add the posts starting every other major section here as they come online:

• Individual Skills Development (Skills Development, Alignment, and Visibility)
• The Test Pyramid and the Chain Reaction (The Test Pyramid and Vital Signs)
• What Software Quality Is and Why It Matters
• Why Software Quality Is Often Unappreciated and Sacrificed
• Building a Software Quality Culture
• Calls to Action

Footnotes