If anything, the quality attributes reinforce each other. Good software design tends to enhance multiple software quality attributes at the same time, for example, by designing for testability (via TDD for example) we also increase the readability, modularity, portability and maintainability.

Additionally the old trade-off between quality itself and productivity no longer applies. We either focus on quality, and find increases in both quality and productivity (as technical debt reduction makes future iterations or maintenance more effective) or we attempt to sacrifice a little quality in the hope of achieving greater productivity, and find (due to the broken window effect) that increases in technical debt make maintenance and future iterations increasingly more expensive.

Apart from that, I agree completely. A lot of teams concentrate only on functionality and reliability, as implemented through testing and bug fixing, but neglect the other aspects.

I do find a lot of people see the ISO 9xxx and lump it into the ISO 9001 certification camp and automatically think big bureaucratic process, so I like to refer them to the fairly identical list of software quality attributes listed by Robert L. Glass in Facts and Fallacies.

(Although ISO 9001 doesn’t have to big and bureaucratic, and can be a good QA component in agile cultures, but that is another topic.)