Quality doesn't suck (at all)

I disagree with previous post written by Pawel regarding quality. And what I'd like to write is too much for just a comment.

- Quality? - all right, but if time permits...

How often do you hear that? If you hear that often it means that probably your product's quality sucks.

Suppose that your team has to implement some stories in the fixed period of time (let's also suppose you are not using Scrum and you are not iteration-oriented). Then the customer pushes the higher management to move the deadline - of course for the earlier date. Team lead will not throw away any stories (what she should do) because the higher management would fire her. What she will do? Tell the developers to implement the same amount of features in shorter time. Developers subsequently will also have to sacrifice something - most probably they will not sacrifice their family life and free weekends. They will sacrifice QUALITY.

According to "Peopleware" book your product requires much higher quality than your customers need. Why? Because Quality, far beyond that required by the end user, is a means to higher productivity.

Reading the same book further there is an excellent example (Janusz who drives Toyota cars is absolutely right :) I will try to rephrase it here. If you think of high quality (either company, nation, culture, etc.), what pops to your mind in the first place? For me it would be Japan. Again, if you think of high productivity, what pops to your mind in the first place? Japan?

The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.

But Pawel complains that there is no need to think on the design, architecture, etc. for too long - just do it. Yes - you're right. That's the XP idea of simplicity - design what you need today - tomorrow you will refactor your code, design and architecture, but if only you will need to do it.

And that's the quality for me! And quality doesn't suck, at all :)