I used to think that quality was about personal traits and state of mind, getting everything right the first time. Over time I've come to realize that quality is iterative. Everything has problems the first time. What separates low and high quality practice in software engineering is the degree to which you follow up on the issues you notice over time.
Will you do it now? If not, will you create a ticket? If that ticket is created, will it be prioritized?
Low quality is simply loss in that pipeline. High quality is simply being engaged enough with the project to constantly be generating these insights, and systematically running them down, until you don't have any more.
Quality isn't only sacrificed due to mismanaged loss in the pipeline. It's also at odds with delivery speed, feature breadth, cost, and itself. Quality is at odds with quality, because quality is not single dimensional!
Quality is not at odds with cost and delivery speed. That's a common misconception, but empirically all sorts of people (perhaps starting with Shewhart) have discovered that a good process leads to lower cost, higher quality, faster delivery.
If anything, low quality is what increases cost and delivery time, by adding expensive inspection, re-work, warehousing of defective product, missed returns on development time, customer disappointment, loss of feedback.
Quality achieved by exhortation ("Try harder!") is at odds with all sorts of things. Quality achieved by straightening out a process designed to produce defects in large numbers -- not at odds with anything, except perhaps office politics.
Will you do it now? If not, will you create a ticket? If that ticket is created, will it be prioritized?
Low quality is simply loss in that pipeline. High quality is simply being engaged enough with the project to constantly be generating these insights, and systematically running them down, until you don't have any more.