4 ms·
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 wa
by saalweachter 7y ago
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 7y agoBeing a QA guy myself, I am of the opinion that this sums it up pretty well: https://en.wikipedia.org/wiki/Project_management_triangle https://en.wikipedia.org/wiki/Project_management_triangle
- saalweachter 7y agoMy 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.