To the poster's credit, he does frame this in terms of balancing concerns. I'd argue the post overstates the non-technical mitigation, but they seem worth being

To the poster's credit, he does frame this in terms of balancing concerns. I'd argue the post overstates the non-technical mitigation, but they seem worth being aware of, and even as a rhetorical device, overstating helps bring them into focus. > The deeper question is why is software quality only loosely correlated, if at all, with business outcomes? Because quality is on a spectrum and context specific: commercial domains need quality levels—you have to set magnitude or quantify in some way. The software profession such as it is, tends to come at this a binary matter (cite pretty much any debate about speed vs quality). That gets, I think, amplified in technical communities where correctness is deemed more important or simply more attainable in terms of claims. > But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. I agree with the sentiment; I actually do think we're in a phase where engineering leverage is underestimated, but would qualify it and say this is different to correctness. What great engineering can do is offer a short term technical advantage (eg "secret sauce") and/or a sustainable one (eg "organisational speed"). It's not clear correctness provides that kind of benefit, unless we want to frame as increasing precision/accuracy/reproducibility of results.