Yeah, that's sorta stuck with me. I know a lot of people who say that the perfect is the enemy of the good.

Well, buddy, that just means that if you have a good solution, it's stopping you from getting a perfect solution.

When I hear "the perfect is the enemy of the good" it's usually in response to the sentiment, "I can't ship this yet; it's not 'perfect'".

In the context of this article: You have a patient who needs to be treated -- today. They can't wait for a hypothetical perfect treatment. Indeed, more fundamentally, the only way to discover a "perfect" treatment would be to use today's least-worst solution, with the determination to measure and improve it continually.

Also the point of the article was that it's not so much the techniques -- which all the CF centers know about and use -- but the aggressiveness of their consistent application.

This isn't about a perfect design. It's about doctors who are willing to coach/goad/persuade patients into doing consistently what they already know they need to do. (And who are willing to be sticklers for consistency to the point of being a bit of a PITA to their colleagues.)

Hmm, no. 'The perfect is the enemy of the good' is one way to sum up the law of diminishing returns, and when you're operating within fixed constraints that matters a great deal, because inefficiently allocated resources have to come from somewhere. I'm a perfectionist by inclination, but in a team environment perfectionism can manifest as tunnel vision and optimizing for a local maximum.

I met people literally unable to finish project until it was perfect. It was never perfect. They just kept iterating and iterating the first part of the projects and the whole thing was never finished.

They were not forced to produce crap by overly active manager, it was not that situation. Manager did not cared for months.

Perfect is the enemy of the good refers to the above problem.

In most contexts I have worked the risk comes not from building the system incorrectly but building the wrong system - i.e. getting the requirements rather than the implementation wrong.

I would generally rather have a less than perfect system that can be used now than a "perfect" system 3 months from now as, in my opinion, you only really validate what you have built when it is in production and in use and delivering value.

The counter-idiom is "Excellence is good enough.". I have used it as a mantra to counter the paralysing need not to act on things unless perfection can be achieved.

Iteration is a pretty good way to deal with this, IME. Get it to be serviceable but mediocre ASAP, then continue improving until better marginal benefits can be found elsewhere.