Quality

Table of Contents

The two types of quality

source

The Japanese define quality in two ways:

  • atarimae hinshitsu (当たり前品質)
  • miryokuteki hinshitsu (魅力的品質)

Understanding the difference between them is the key to building products that users love.

atarimae hinshitsu (当たり前品質)

Atarimae hinshitsu is the idea that things should work the way that they are supposed to.

It's a purely functional requirement and is satisfied when the product completes the job that it was designed to create. For example, an IKEA chair meets the atarimae hinshitsu quality expectation because it's made to sustain and fit a person of average height and weight. Being reliable and robust is a significant component of quality, and there is elegance in things working according to their function.

miryokuteki hinshitsu (魅力的品質)

Miryokuteki hinshitsu, on the other hand, is the idea that things should have an aesthetic quality.

It's basically the kind of quality that fascinates you. This could include things like visual appearance, sound, or anything that gives personality to a product. For example, a Herman Miller chair could be considered miryokuteki hinshitsu because it goes beyond its functional requirements. There's a distinct touch, smell, texture, and design that makes it unique; it's a “special refuge from the strains of modern living," as they say. These aspects bring added value to the product and make it desirable.

what are you optimizing for?

Quality is not about trade-offs; quality is about philosophy. You can choose to achieve both atarimae hinshitsu and miryokuteki hinshitsu so that a product will meet users’ needs and be delightful to use.

However, when thinking about quality, it's crucial to have self-awareness. You have to look at what you are optimizing for as an individual and see if that matches with what your team is optimizing for. If there's a mismatch, there's a high chance that you'll end up with a suboptimal product.

For more on this topic, I recommend watching Jiro Dreams of Sushi, a documentary directed by David Gelb, and How to Build Products Users Love, a talk by Kevin Hale.

Quality is Systemic

src

  • Software quality is more the result of a system designed to produce quality, and not so much the result of individual performance.
  • Well-designed testing harnesses that make it easy to write tests, and a team/company culture that encourages writing good tests and gives engineers the time and space to do so.
  • Easy-to-use, high-fidelity development and staging environments, and culture free of pressure to push code to production before it’s well-proven.
  • Codebases that are documented, well-factored, and sufficiently commented – which is the result of a development cadence that allows generous time for these activities.
  • A workplace with high psychological safety that lets people feel comfortable asking for help when they’re stuck, and …
  • … when failures happen, they’re reviewed blamelessly, and the system is improved to prevent future failures of that class.

There are both technical and human factors involved in systemic quality, and these factors intersect and interact. In the best case they form a virtuous cycle:

  • Great tests catch errors before they become problems, but those tests don’t magically come into existence; they require a structure that affords the time and space to write tests.
  • That structure works because engineers are comfortable speaking up when they need some extra time to get the tests right.
  • Engineers are comfortable speaking up because they work in an environment with high psychological safety.
  • That environment exists in part because they know that production failures are seen as systemic failures, and individuals -’t be punished, blamed, or shamed.
  • Outages are treated as systemic because most of them are. That’s because testing practices are so good that individual errors are caught long before they become impactful failures.

Implications:

  • If your team is producing defective code, consider that it may not be because they all suck at their jobs. It’s probably because the environment isn’t allowing them to produce quality software.
  • Instead of spending tons of time and effort on hiring because you believe that you can “only hire the best”, direct that effort towards building a system that produces great results out of a wider spectrum of individual performance.