"As a developer, I work in quality ENSURANCE. It is my job to deliver quality code to the tester on my team, whose job is quality ASSURANCE."

In the above statement there is misconception. The task done by testers is not a QA (Quality Assurance) task but in fact it is a QC (Quality Control)task. Quality Control is about finding defects once they are in the code (product) whereas Quality Assurance is interesting in preventing defects from entering to the code (product) To make sure defects are not introduced QA is interested in Process. Assuming the process is there to make code (product) less defectful, QA guys check if the team follow the process such as XP prenciples...

Orhan - I think this one varies from company to company. What you say makes sense to me, but in my experience I've only seen QA departments w/ testers - not QC departments.

Anyone else have any insights on this?

Orhan Mike Kalayci is right, but the wrongness is pervasive. A lot of people call it QA when it's really QC, sometimes because they don't know the difference and sometimes because they only want to want to seem to be quality-minded.

QA is involved in production, QC is a gate that produced materials must pass through. You are doing QA so that QC is easier. It is so pervasive that I didn't realize you'd made the mistake until someone else pointed it out.

TQM had a lot of good ideas, but people made a lot of mistakes applying it to software. They didn't grasp that software production is really R&D and not repetitive the way that a lot of other work is. Until we had the short iterations, they could not even apply pipeline management ideas to it. I think that the RAD, XP, and Agile people finally started applying the TQM ideas to software but only in retrospective did people realise that this is so.

But what you're saying is still the right thing, with the words rearranged. :-)

The ensurance/assurance thing is so much nicer than ensurance/control. C'est la vie.