Tuesday, November 10, 2009

Sufficient Quality

How do you measure yourself? How do you know your release is of acceptable quality? You've found a lot of bugs, and you've fixed a lot of bugs. You have a set of great new features, and you've done all sorts of interesting security and usability testing. It's a great release! Or is it?

Your release is of sufficient quality if your customers are sufficiently happy.

The real trick here is to define "sufficient". You could have hundreds or thousands of bugs in the product, and if your customers don't hit them or don't mind them (or think a bug is a feature!), then it's still a release of acceptable quality. You could have a total of 5 bugs, but if your customers hit them a lot and they're bad, then this is not a release of sufficient quality.

So if you want to know how you as an engineering (and requirements gathering and sales) team are doing, ask your customers. They're the ultimate arbiters.


  1. If I hacked together a buggy piece of garbage, and enough people with really low standards declared they loved the end result ... well, I don't know that I would feel ethically comfortable saying it was of "sufficient quality".

    Maybe sufficient to the end-user or customer or client -- but not me.

  2. Joe, sure, but you're also your own customer. "Customer" is more than the end user. It's also you, the developers you work with (maintainable code, anyone), your support team, your sales guys, any regulatory agencies involved, etc.

    "Customer" is really "anyone you serve with this product". And it has to be sufficient for all of them - including you.

  3. Satisfying the customers requirements with no visible defects is simply the baseline, the low bar, its the "given" before we even begin to talk about quality. The bulk of software quality is internal, (often) invisible to the customer, and affects attributes like technical debt, software design, maintainability, the presence of anti-patterns.

    A lot of big balls of mud satisfy all requirements without any visible defects. And that is all the customer can be happy with. He doesn't know that it is unmaintainable junk.

  4. Kurt, see my comment to Joe. You are a customer, as is the developer you work with. Writing an unmantainable ball of goo doesn't meet your developer-customer's needs and will make them insufficiently happy.