Internal and External Quality

In Extreme Programming Explained, Kent Beck writes:

There is a strange relationship between internal and external quality. External quality is quality as measured by the customer. Internal quality is quality as measured by the programmers.

He goes on to explain the human effect on quality:

If you deliberately downgrade quality, your team might go faster at first, but soon the demoralization of producing crap will overwhelm any gains you temporarily made from not testing, or not reviewing, or not sticking to standards.

In this light, it looks as if we should always strive for the highest standard of quality. This would, of course, make me very happy. But is the customer willing to pay for it?

I think the important concept here is the difference between internal and external quality. Whenever I meet someone who works in an XP environment, they always tell me that one of the reasons they love coming to work each morning is that they know they'll be allowed to do their best work. If you take that away, XP won't work. It's good to have 100% successful unit tests. In the long run, it speeds up development time. Internal quality should be a given.

External quality can be defined as a set of features. For example:

• Whenever the user makes a mistake, a user-friendly error screen appears.

• It's impossible to crash the server via the user interface.

• The system can handle a hundred concurrent logins.

• The system will stay up 99.995% of the time.

Negotiating with the customer on external quality doesn't mean skimping on acceptance tests or deliberately producing unstable code. It means that the customer asks for a certain standard of quality and pays for it. If they want a system to handle all exceptions, that should be in the story or multiple stories. Story 1 says to implement this functionality; story 2 says to make the functionality work with n concurrent users hammering it.