"Software quality" is such ambigously defined term that all of these can simultaneously be true (for different products):
* software quality is (more) important
* software quality is not (very) important
* bugs are not important (aka "i don't test, but when I do, it's in production")
* the less bugs you have the better, but they're not gonna kill you
* bugs are safety-critical
* slow delivery is fine
* slow delivery is not fine
In the last 20 or so years working as software developer professionaly, in various teams and quite different projects, I've noticed that:
* people (decision makers, software buyers/clients) always say they want higher quality
* same people very rarely want to back that up with their budget
* people almost always prefer more features to more quality (even when explicitly told that more feature is not a good thing for eg. MVP stage of a startup)
* most people except dedicated QA engineers can only think of a happy path (if everything works the ideal way); this includes not only other engineers (who try to think up failure scenarios but often miss important ones), but also designers (when have you ever seen a design mockup for "DNS lookup failure connecting to the server" case?), and definitely product owners or clients (in context of a dev agency)
* I have never worked on a nontrivial software project that didn't change requirements/scope
Myself, as with many other software developers who chose this field out of passion and not stratospheric wages, was for a long time appalled by this apparent lax approach to quality? Don't you want to have the best possible product?
But working with a lot of diverse clients while doing dev agency work, and running several startups myself, has taught me that software quality is not, and (it pains me to write this) should not be, the top priority. Product-market fit, treating your customers well, having a sustainable monetization strategy, marketing and sales ... if you don't execute well on those, nobody will notice the (lack of) quality[0].
In most organizations (except the ones that are swimming in cash) it's a tough act to balance all of the above. While I wish for all the projects I work on to be the best they can be, a programming work of art if you will, I can certainly empathize for people who must prioritize otherwise.
[0] unless the quality is safety critical, in case I need to point this out explicitly.
* software quality is (more) important
* software quality is not (very) important
* bugs are not important (aka "i don't test, but when I do, it's in production")
* the less bugs you have the better, but they're not gonna kill you
* bugs are safety-critical
* slow delivery is fine
* slow delivery is not fine
In the last 20 or so years working as software developer professionaly, in various teams and quite different projects, I've noticed that:
* people (decision makers, software buyers/clients) always say they want higher quality
* same people very rarely want to back that up with their budget
* people almost always prefer more features to more quality (even when explicitly told that more feature is not a good thing for eg. MVP stage of a startup)
* most people except dedicated QA engineers can only think of a happy path (if everything works the ideal way); this includes not only other engineers (who try to think up failure scenarios but often miss important ones), but also designers (when have you ever seen a design mockup for "DNS lookup failure connecting to the server" case?), and definitely product owners or clients (in context of a dev agency)
* I have never worked on a nontrivial software project that didn't change requirements/scope
Myself, as with many other software developers who chose this field out of passion and not stratospheric wages, was for a long time appalled by this apparent lax approach to quality? Don't you want to have the best possible product?
But working with a lot of diverse clients while doing dev agency work, and running several startups myself, has taught me that software quality is not, and (it pains me to write this) should not be, the top priority. Product-market fit, treating your customers well, having a sustainable monetization strategy, marketing and sales ... if you don't execute well on those, nobody will notice the (lack of) quality[0].
In most organizations (except the ones that are swimming in cash) it's a tough act to balance all of the above. While I wish for all the projects I work on to be the best they can be, a programming work of art if you will, I can certainly empathize for people who must prioritize otherwise.
[0] unless the quality is safety critical, in case I need to point this out explicitly.