Hacker News new | ask | show | jobs
by DannoHung 4428 days ago
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.

4 comments

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.