Remember to Consider system's expected lifetime during design and before making improvements.
Don't spoil a perfectly good program by over-refinement. Move on and let your code work in production for a while.
Gabriel "Worse is Better"
Conversation with Nicolas Grilly:
So the real question, is when should we stop submitting improvements to the same components or products. When is it good enough? My own heuristic for that has two sides:
- How much the people working on that product/component can be pushed towards a better product. Some people really love the challenge, some will end up thinking this is about them. There is that situation where the reviewer thinks the design or the code is bad, but the author thinks it is good enough and the reviewer is just bike shedding. In that case, if the reviewer is pushing for improvements, the code quality may be higher short term, but there is a risk of decreasing future code quality if the author becomes bored, annoyed and/or demotivated.
- How much the component is critical? If the component is critical and/or will be used for a long time, then of course it is very important to focus on code quality. Any shortcut here will hit you hard later. But if the component is only used internally for a minor application, and/and will be replaced in a few months, then it doesn't make sense to invest too much in high code quality.