Quality and Suffering in Software Delivery

Cross-posted from staffordwilliams.com.

The way I deliver software is grounded in a belief that quality matters and is the route to less suffering. After building software for a long time my approach has become tacit knowledge - helpful in work I'm directly involved with but elusive to others, and more recently, AI. I need to write it down but I've been extremely good at allowing the annoying complexity to keep me procrastinating. For every guideline I have, I can think of exceptions and a context where it doesn't apply. But the efficiency of having it written down is now higher than ever - not only can it help me clarify my thinking, and you to understand my approach, but I can use it to build or evaluate AI tooling to help teams deliver software better and faster than ever before.

Software delivery is full of decision making, and as long as you often make the right decisions, then the suffering can be mostly avoided. However it turns out that making the right decisions is really hard, and it's much easier, tempting, and at times incentivised, to make the wrong ones. Over time these wrong decisions compound and teams are plunged into unnecessary suffering. Sometimes the decisions are forced on them by elements outside their control, but often it's self inflicted. Sometimes wrong decisions are made due to ignorance, or miscommunication, or misunderstanding.

Collaborative delivery is complex. A bunch of individuals with different perspectives and expertise and personalities need to align on a shared goal and work together to achieve it. But this person didn't understand that person even though both people thought they did. Now some people have put a bunch of effort into solving the wrong problem and a bunch of other people are saying that effort was wasted and we're frustrated and demotivated and at this stage probably largely dysfunctional. If this sounds like the suffering you've experienced then wouldn't it be great if there was a way to avoid it?

The good news is that all you need to do is ensure that everyone understands each other, and together, do as little as possible. The bad news is that it's very hard to do so and intuition (wrongly) advises not to.

My approach to Software Delivery

At a high level my approach is a focus on quality in the process of delivery, how we build software, and how the sofware is, or will be, used. Going deeper I see a cross-functional team that collaboratively iterates software towards some goal. The team engages stakeholders and subject matter experts and assimilates them if necessary. They design solutions and build and operate systems that amplify the stakeholder's capabilities. The team discerns from noise of many possible directions the right direction to take and validates their understanding with experiments performed in prod. The team delivers in small increments and gets feedback early and often. They use the feedback to adapt and improve their approach. They automate everything they can and continuously improve their ways of working.

An acceptable level of quality is determined and maintained, and as the team improves their quality expectations do also. The environment that they operate in however will constantly challenge the team's commitment to quality. An irrational barrage of arguments to reduce quality will be presented to the team regularly. The increasing complexity of system scope and the endless demands of changing stakeholders will require resilience and discipline to maintain quality. Or, put another way, suffering will constantly try to creep in and the team must constantly fight it off.

Why Quality?

For a while, I struggled with whether quality really mattered. I read, and hated, yet continued to ponder, Zen and the Art of Motorcycle Maintenance. I joined teams that hadn't focused on quality and helped them out of their suffering. But I left those same teams and saw quality slip. I thought about all the teams that delivered software without me. I ranted about quality and why we should automate everything and why we should understand each other better. I thought about the successful outcomes I led teams to deliver before I focused on quality. Maybe I was scared to speak up against suffering. Certainly my tolerance for it was higher back then. Ultimately I concluded that you don't need quality to deliver software. It's just faster, and less painful, and easier, and more fun, if you do.

My preference is to avoid suffering and quality is the way to do that. Sometimes it's easier to understand quality as a requirement when contrasted with results that are lacking in quality. Non-intuitively, when speed matters (and it rarely doesn't), disregarding quality to arrive faster seems like an easy and almost free decision to make. Confusingly, the effect of low quality is not often immediate and so the decision to sacrifice quality for speed appears to payoff in the short term. But with each shortcut taken, the system marches further towards the big ball of mud, gradually becoming harder and slower to change, and suffering becomes the norm.

Even in systems that were initially built with quality in mind can deteriorate over time without continued attention to quality. Decisions to outsource development to cheaper providers, or to lower the bar for hiring developers, or to generate code using AI tools without steering move us further into suffering because the quality expectations are lowered. It's possible to have these approaches work but only by including quality as a first class concern. But quality itself is a complex topic, difficult to define and communicate, and heavily dependent on context and capability - both of which change over time.

What is Quality?

While subsequent posts will detail how to achieve quality within my particular approach to software delivery, I pondered first writing about what quality is and how it applies to software delivery in general. This was a mistake, as it appears we've been trying to define it for more than 50 years and still haven't reached consensus. ISO 25010 is the latest International Standardized model for (software) product quality and ISO 25019 covers quality in use and a concise summary of both is available here.

As both a programmer, and a leader of teams that deliver software, my interest also extends to the quality of the process by which software is produced. Developer Productivty for Humans, Part 7: Software Quality includes a Process Quality in their Four Types of Software Quality model:

The DORA research program's (previously four, but now) five metrics implicitly measure aspects of process quality across two categories: Throughput and Instability.

The topic is dauntingly large, so large in fact, that I could dedicate this entire website to the topic alone and likely never cover it all. Instead, let me state three truths about quality that underpin my approach to software delivery:

• Quality should pervade all aspects of software delivery.
• The enforcement of quality should be as automated as possible.
• Quality is context dependent and the quality bar should be continuously raised.

My experience delivering software has shown me that guiding software delivery by these ideas leads to less suffering for all involved. But you don't need to take my word for it. Many others have written extensively on this topic. Thanks to the internet I don't need to continue down the rabbit hole of trying to define or argue for quality myself and can instead focus on illustrating how I apply it in practice.

Why Quality Matters

• See Why Quality Matters, a summary of foundational works from authors like Martin Fowler, Gerald Weinberg, and Fred Brooks alongside recent practitioner research from DORA, Stripe, and leading engineering organizations to address what quality means for teams building software today.
• Or, see Key Sources and Further Reading to read directly from the sources.