Ron, I think you are making a wrong assumption about the people you are responding to. Many programmers involved in these kind of discussions write good code and work in companies that produce reasonably good code. They are beyond problems of expressive names and code duplication.

And if you accept that, the question is: Do you agree that there is a level of code quality beyond which there are diminshing returns to further improvement? If so, what is it in your opinion? If not, when do we determine how to ship software?

On the contrary, Krishna. My point is that code improvement done commensurately with one’s skills, is never costly, whether you are beginner, intermediate, or expert.

As to your second paragraph, I believe I addressed that in the first paragraph of the article.

I think there is a confusion here between “code quality” and “coding rules”. They are not the same. For example: removing duplication improves quality. Adhering to a rule indicating that you must name all value objects with the suffix “VO” does not. In other words: Just adding new rules – how silly they may be – does not necessarily improve quality. That means using static code checkers, turning all rules on and forcing people to code in such a way that not a single warning must appear has no positive impact on quality. On the contrary: people will get distracted from implementing “real” quality in an attempt to adhere to arbitrary rules.
So there is a distinction between “real” quality and “percieved” quality as a result of oversimplification of the problem and it’s only “real” quality that should be permanently improved.

Sebastian, as far as I can determine, I have never in my life written about coding rules, nor recommended using static code checkers, nor suggested forcing people to do anything.

I would prefer comments that are a bit closer to the topic in the future.

Thanks.

Sorry Ron, it seemed to me that Krishna implied something in that direction but I may be wrong. All I wanted to say is that people should concentrate introducing real quality by doing what you suggested in your post and not get distracted by things that sometimes pretend to improve quality but do not improve it in practice. However, I didn’t claim or at least I did not mean to claim that you recommended the things you mention in your last comment.

Sometimes it can come down to a simple question of pride. Some developers see their current job as merely a stepping down to somewhere else (often in management, they hope), and therefore don’t necessarily perceive any value in either writing well-structured algorithm or cleaning up bits of code as they go. The best developers I’ve worked with, on the other hand, are the ones who think that any code worth writing is worth doing right, and they take pride in their work no matter how long they stay in one place. They also understand that it NEVER takes longer to do something well, if you include the clean-up time that inevitably is required, and usually at the worst possible time.