I’ve thought for years in terms of two kinds of software quality: “internal” and “external” quality. The idea is that “internal” is essentially the stuff that helps developers to go fast (or forces us to go slow) over the long term; and “external” is the stuff that non-developers can observe directly, without having to look at the rate of change in progress. But lately I’ve been thinking that (as with many things) there are a lot more dimensions than two in play here.
This isn’t a terribly original idea, that many things are important in software development, but bear with me. What makes a given software product or service high quality?
Many perspectives
Here’s one framing of “external” and “internal” quality:
- How well does it satisfy stakeholders' expectations under normal execution (the “happy path”)?
- How easily can it be evolved over time as new features and requirements are added?
But there are plenty more questions we could ask that absolutely affect our ideas about quality:
- How gracefully does it behave under slow networks or partitions?
- How clean and intuitive is the user interface?
- How well-protected is it against nefarious attackers?
- How deeply and easily can we observe it as it runs in production?
- How does it do at making money, or saving money, or achieving whatever its strategic goals are?
Most software delivery work is, at least implicitly, striving for all of these, and probably more. And it’s not hard to think of specific folks/roles/departments who primarily think about quality in each of these terms.
Having it all
What’s interesting to me, though, when I zoom out, is that I’ve literally never seen a single person demonstrate excellence across all of these dimensions (myself certainly included). And these are just the first handful things that come to mind! I assume it's possible for one person to do high-quality work in all of these areas, and that I just haven’t seen it, but it sure seems hard.
Nevertheless, we all seem to want, and expect, our product and services to demonstrate high quality in all of these directions. This doesn't happen automatically in my experience, even in a team of folks who care a lot and learn quickly. So how can we do that?
We can improve our skills, maybe even try to learn everything. We can build cross-functional teams with individuals skilled in each of these areas, and trust them to ensure excellence in their area of expertise. We can provide some centralized support from experts to help many teams learn where the quality bar is along these axes. Or we can explicitly decide that some of these axes of quality are less important for now.
Expanding our views on software quality helps us recognize where we need help. It highlights our opportunities to grow as both individuals and teams—to improve our existing skills and to develop new ones.
As software developers—as we’re constantly learning the latest languages, frameworks, libraries, and other tools—it’s easy to forget about the quality outcomes we’re trying to drive. Software quality exists along multiple axes. And I think as we strive for high quality in the areas we know well, we should also be looking at how we can increase quality in the other areas. I’m asking myself right now, and I’d encourage you to do the same: what axes of quality do I need growth in, or help with, to deliver the quality software that the world expects?