How do you define quality in a software product? Few defects, no crashes, happy customers?

I believe that software quality really comes down to a few metrics. One is the amount of defects that makes it out of your lab. Another is your ability to maintain the product throughout its life cycle.

The bug metric is one I think most people in the software industry would agree on. So one might ask, why are we still creating them in high volume? Are we really at a point where it is not feasible to lower the rate at which we introduce bugs? I hardly think so. I think developers need a change of attitude towards bugs.

I like to tell myself that for every bug I pass down the "software assembly line" to the testers, I am responsible for the time they waste on finding, reproducing and reporting this bug. Or even worse, if they don't find it I will be responsible for wasting my customers' time.

In case the testers actually find my bug I am furthermore responsible for delaying the entire feature by introducing a need for a "bug fixing phase" where I will be debugging issues that should never have made it into the code.

If I introduce multiple bugs I will most likely also be responsible for wasting somebody else's time on prioritizing them.

I think most developers know that the total cost imposed by defects, rises exponentially over time. But what is really important, is that developers need to accept that they are the key to introducting less bugs, and managers need to accept that trying to push developers to deliver features faster is not going to lower the defect-introduction rate.

What do you think?