Unless you can coach and pivot someone from that "must make everything perfect" mentality to one where they can take a more pragmatic approach to things.
This is really hard. Really hard. It can take years to get an engineer to that sweet spot.
When I build teams I usually select "builders" and "improvers." Improvers can't create new systems because they spend all day theorizing edge cases and what-ifs. Builders can't improve systems because they spend all day theorizing new systems to replace the legacy one they see as imperfect. You also have to get the right ratio of those two. Too many builders gets you a lot of brittle systems and a huge JIRA backlog; too many improvers creates stagnation.
This is part of a larger spectrum of developer preferences: openers, sustainers and closers.
Openers want to create new things, they love a blank canvas. Where some people are scared of this, they thrive in a place where you can lay down rules, define parameters, and create structures that are a good fit for the problem domain.
Sustainers like to work within a project that's evolving, but largely defined, where they can get a lot of things done and move the ball forward. They may create more work along the way, go on excursions, but the overall direction is roughly towards the goal. They have to make many compromises along the way.
Closers like finishing things, closing out bugs, wrapping up features, taking care of a myriad of loose ends and "TODO" type tasks. They're interested in completing work, not creating more work. This is where you have to make harsh judgement calls, implement ugly hacks, anything to wrap things up.
It's rare you'll find someone who excels at or even likes to do all three. We often have our bias.
I disagree that "closer" is a distinct class. It's a necessary aspect in any class. In most companies if you don't "close", you get fired or put on a PIP (and you don't get coffee). There is another class that at some companies where closing isn't necessarily expected: "tinkerer". They just mess around with various projects to learn and make suggestions, but they don't have to close to keep their job.
I've never heard it stated that way, but I can strongly identify with this. After 18 yrs in the industry, I am finding more and more that I enjoy improving much more than building.
When I build teams I usually select "builders" and "improvers." Improvers can't create new systems because they spend all day theorizing edge cases and what-ifs. Builders can't improve systems because they spend all day theorizing new systems to replace the legacy one they see as imperfect. You also have to get the right ratio of those two. Too many builders gets you a lot of brittle systems and a huge JIRA backlog; too many improvers creates stagnation.