What Defines Software Quality?

I could get into the whole definition of Quality, and go off on a digression about the false dichotomy of separating Truth And Quality, about the need to fuse Rationality and Romanticism, and then end up telling you to Just Go Read Zen and the Art of Motorcycle Maintenance. 

Mind you, that would be my attempt at ignoring the original question (See?  Thats why I could never be a politician!), and we can't have that, can we?

Back to Software Quality - the underlying issue in defining it is that it really depends on where you are standing.  Lets just assume that you know what you care about vis-a-vis methodology, i.e., you want modular code, written in erlang, using Strong OTP Principles, etc, etc. etc.  
At this point, you should probably look for Software Quality based on the people involved.  i.e., if you have quality people, you'll probably have quality software.  
(Joel Spolsky has a great writeup on this, which I am absolutely not going to encapsulate here. Just Go Read It.(*))

Anyhow, the point behind The People Approach to software quality is that at the end of the day, its about compromises.
Yes. Compromises.

1. Business conditions determine the constraints associated with your project
2. These constraints are invariably things that your people really have very little control over
3. These constraints have existed, and will exist forevermore.  Ok, not the same constraints.  But some constraint will replace the current one. Forevermore
4. If you have a quality software team, then they will build to current (and anticipatable future) constraints.
5. And to the extent that they can't anticipate future constraints, they'll build the software so that it is adaptable.

This, of course, brings up a Very Important Point about code quality, viz.

Code quality is inextricably linked to the constraints under which the code was developed.  

Or, to put it differently, virtually all code is going to be the best code that it can be given the constraints under which it was developed.(**).   

The point behind all of this?  Get to know the people who built the code, and then find out what their constraints were - what were the crisis, when did they have to panic to meet deadlines, etc. 
You'll probably find have a much better understanding about the Quality of your code, than any number of code reviews (***)

And thats about all I have to say about Software Quality.  If you want to get into more detail, get this journal, and then spend the next six months not actually being productive (yes, I'm being snarky.  Sorry…)

(*) Of course, for the people out there who refuse to follow links, the The Joel Test for Quality Software Teams is

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

(I know some of the above is obvious, but seriously, you'd be surprised)

(**) Yes, there is the mythical environment in which the Perfect Development Team had infinite time and infinite choice in developing the Perfect Application.  I also have recently come into possession of a bridge in Brooklyn, which I have for sale…

(***)  Code reviews are A Pure Good.  I am *not* knocking Code reviews.  Really!  In fact, for extra credit, what you want to do is at least some reviewing.  Mind you, this is not to make sure that they have Getters and Setters everywhere (ack!).  You should have figured that out when you spent days talking to the developers (you did spend days, right?  Not hours?  Because if you think you got to know them over a few hours in a conference room, well, remember that bridge I have for sale?).  The point behind the code review is to see if you find Beauty and Elegance.  And no, I'm not going to define either.  And yes, I may be substituting one loose term for another (Quality?  Beauty? Elegance?  What next?  Wisdom?), but frankly, Elegant code is pretty easy to identify (if you've ever seen it, you know it.  If you don't know it, you haven't seen it)