Thursday, April 29, 2010

The Embarrassment Test

When you release software, there's usually some quality bar that must be met. This is often expressed in terms of clean runs of automated tests, number and type of tests performed and passed, existence of supporting documentation, etc.

There's one more test: the embarrassment test. It's a simple test:

Will I be embarrassed if this build ships?

The embarrassment test gets to the heart of what you care about in a given release, showing the quality bar that matters to you.

For example, I'm working on a product that has simplicity of API as one of its core principles. So my embarrassment test includes looking at the API. Anything that seems sloppy, inconsistent, or kludgy is embarrassing. That's not something that would appear in a traditional release checklist, but it's something for which we will hold a release.

What's in your embarrassment test?


  1. How embarrassed? :-)

    There are some people that argue that this will tend to do too much polish, see for example
    Reid Hoffman

  2. It's true there is potential for too-easy embarrassment. The way I think of it is that there's probably something embarrassing that you don't know about. So you shouldn't ship if you're embarrassed by things you DO know about, because that's just piling on the stuff you haven't thought of.

    Also, embarrassed is different from "could be cleaner" or "could be better".

  3. The most worthy embarrassment test for me is "Would I like to be a user of this piece of software?" If I can truly answers this question with no, then it better shouldn't ship.