[saalweachter]

A lot of the trouble is that good QA -- and good engineering practices in general -- usually comes down to some equation like velocity x quality = $. If you want to increase your code quality, you either have to slow your velocity or jack up your $'s -- and usually you end up doing some combination of both, going a little bit slower and spending a little bit more money.

And if there's one thing people hate more than going slow it's spending more money.

[baal80spam]

Being a QA guy myself, I am of the opinion that this sums it up pretty well:

https://en.wikipedia.org/wiki/Project_management_triangle

[saalweachter]

My reformulation is mostly out of ignorance, but since this is the internet, I will contend in a fit of pique that in modern software development, velocity (which is basically scope / time) is more interesting than the two factors individually, because so many of us live in a nightmare world where there are not finished projects, just continuous iterative release cycles.