Hacker News Reader

Often it's not dev managers, but a level above who don't prioritize QA engineering because they see it as a cost center and find it difficult to quantify the risk. If it's not leading to growth it is de-prioritized until fires are burning.

View on HN

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.

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

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.

Reply on news.ycombinator.com