The so-called Pragmatic Programmers have some interesting views. I've only read a couple of interviews with them but they seem to be interested in agile development but are also rational enough to say "sometimes pure exreme programming (XP) doesn't work in all situations, so use your head." Like XP and most agile processes, they seem to prefer enabling over directing.

The broken window theory is one of the more interesting ideas. The gist of it: if you compromise on quality even a little bit, the project could spiral out of control. So you have to stay on top of little problems and not let them hang around -- because if a lot of little problems are in the code, then developers will just say "well, what's one more problem? It will save me five minutes" and get lazy.

Quality includes not just fixing bugs, but also the code conventions and little things. Code readability can impact how quickly you can understand the code and refactor. Agile processes are maintenance processes, with high code turnover ... you need to write your code to be easily understandable, refactorable and maintainable. You should be able to go to a piece of code and not be able to tell who wrote that code. Everyone on the team should be writing in the same way, so that they may read it in the same way. Most people are not in that mindset. They just want to write a piece of code and move on to something else. Maybe they'll come back to fix a bug but otherwise the code is perfect, right?. In XP you will almost always come back to refactor the code, so it instills a sense of responsibility to be maintainable.

If you rigorously fix "broken windows" -- small problems -- just like the pragmatic guys say, then the quality will stay high because no one wants to be the first one to start writing crappy code. Just like in XP where no one wants to check in a test that doesn't pass because it breaks the build. If you start allowing broken tests, then the value of your whole test suite decreases.

Where this might differ from XP is that XP has a focus on the riskiest problems. Some developers might interpret that as being "I have new features that are more important or risky than these little bugfixes, so I have to implement them now instead of fixing bugs."

But if you take the pragmatic view into account, then the bugs themselves become very high risk to the project on the overall quality scheme of things for the reasons I talked about above. So they become the riskier issues you should be attacking first, at the expense of new features but for the long-term benefit of the project.