And you are here why?

/via CommitStrip  

Seriously. You know what " Technical Debt " is, right? Ok, heres the (official?) Wikipedia definition   Technical debt   (also known as   design debt   or   code debt ) is a   neologistic   metaphor referring to the eventual consequences of poor or evolving   software architecture   and   software development   within a   codebase . The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future. And in this - somewhat purist - sense, " Technical Debt " is absolutely valid. The problem arises in the way it is almost invariably used, viz., as an excuse to not do something. Herewith a simple exercise - t...

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 ...