Of course, it depends on your definition of quality, but for the sake of argument I'm assuming that we're including things like test coverage, code complexity, code cleanliness/readability, structural soundness (cohesion over coupling, the single reponsibility principle etc) and so on.
The point with all of these things is that as much as they might seem to be a waste of time when people can be hacking on something else, they (imho) save orders of magnitude more time than that in terms of maintenance of a codebase: being able to quickly fix issues as they occur; how quickly new developers can grok the codebase; how easy it is to add new features that were not part of the original design.
Unfortunately I have no hard data to back that opinion up, but it is what I intuitively believe to be true based on experiences.
It is dependent on the definition of quality. I'm not saying just throw crap code over the wall as quickly as possible! I've seen the consequences of that often enough. But I've also seen a lot of premature optimization masked as "quality", and at a certain inflection point, it becomes so time-consuming that it threatens the project.
For example, do you really need 100% unit test coverage of all corner cases?
If it is the front end to a banking app, or otherwise involved with account security, then yes. If it is an "Angry Elves" game with no login, then probably not.
As always, these memes are useful to guide/test our thinking, but not very useful if used without reflection.
Of course, it depends on your definition of quality, but for the sake of argument I'm assuming that we're including things like test coverage, code complexity, code cleanliness/readability, structural soundness (cohesion over coupling, the single reponsibility principle etc) and so on.
The point with all of these things is that as much as they might seem to be a waste of time when people can be hacking on something else, they (imho) save orders of magnitude more time than that in terms of maintenance of a codebase: being able to quickly fix issues as they occur; how quickly new developers can grok the codebase; how easy it is to add new features that were not part of the original design.
Unfortunately I have no hard data to back that opinion up, but it is what I intuitively believe to be true based on experiences.