• Make many different bets, "flaneur" strategy (Nassim Taleb) ⇒ err on the side of moving on, trying more things.
  • Contra: Finish things, particularly, migrations.
• 80/20 principle: move on when hit the diminishing returns.
• The bulk of the value of many features and projects tends to become available abruptly at some level (‣). Agile strategy suggests that the feature should be released at this minimum level to collect feedback: either from users, or in the form of system's behaviour in production: ‣.
• Always work on the highest-leverage things: re-prioritise after each PR, apply the Impact-Confidence-Easy prioritisation model (or Earl Beede's prioritisation model)

Remember to Consider system's expected lifetime during design and before making improvements.

Related:

• Explore/exploit tradeoff (‣)
• ‣
• ‣ (focus vs. moving on, in career)
• Balance within an organisation
• ‣
• ‣

References

‣ 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.