Others have commented on "process" issues related to quality; I'd like to focus on "people" issues, the human aspect. My view is that people have a bigger impact on quality than process; that a team of low quality developers will produce a low quality product, no matter what process they use. A key quality issue then is how to attract, identify, inspire and retain quality people. (Google, for one, spend a lot of time and money on recruiting, endeavouring to hire only high quality people).

Chapter 4 "Quality - If Time Permits" of Peopleware is worth a read. Quoting this review:

Philip Crosby wrote in his book "Quality Is Free" that letting the builder set a satisfying quality standard of his own will result in a productivity gain sufficient to offset the cost of improved quality...

A policy of "Quality - If Time Permits" will assure that no quality at all sneaks into the product. Hewlett Packard is a company that makes a cult of quality, reaping high productivity due to high, builder-set quality standards. Their sense of quality identification increases job satisfaction resulting in one of the lowest turnover figures in the industry.

Power of Veto - Hitachi Software and parts of Fujitsu give project teams an effective power of veto over delivery of what they believe to be a not-yet-ready product.

Joel Spolsky tries to strike a sensible middle-ground between "sales-driven" and "developer-driven" companies by creating a Development Abstraction Layer:

You've got your typical company started by ex-software salesmen, where everything is Sales Sales Sales and we all exist to drive more sales. These companies can be identified in the wild because they build version 1.0 of the software (somehow) and then completely lose interest in developing new software. Their development team is starved or nonexistent because it never occurred to anyone to build version 2.0... all that management knows how to do is drive more sales.

On the other extreme you have typical software companies built by ex-programmers. These companies are harder to find because in most circumstances they keep quietly to themselves, polishing code in a garret somewhere, which nobody ever finds, and so they fade quietly into oblivion right after the Great Ruby Rewrite, their earth-changing refactoring-code code somehow unappreciated by The People.

Both of these companies can easily be wiped out by a company that's driven by programmers and organized to put programmers in the driver's seat, but which have an excellent abstraction that does all the hard work to convert code into products below the decks.