Hacker News new | past | comments | ask | show | jobs | submit login

In practice, trying to satisfy everyone's target for perfection took forever and immediately after launch the vision of perfection was revealed to be incorrect anyway; this is the classic "waterfall" failure mode. It also (incorrectly) perceived the cost of delay to be zero.

If you are optimizing for something like "actual business value delivered over time" in most typical business contexts (maybe not SpaceX), you are better off putting a ceiling on everyone's idea of perfection, whether that's stakeholders, designers, devs, etc and focusing on launching quickly. From there, you can choose whether to continue to iterate, or move to something else, based on real world feedback.

It's not really being against perfectionism; there are just many projects and diminishing returns.




Right. Perfection can be the enemy of the good. It's that it's not a particularly a helpful critique. To use the article’s concept, it’s the wrong scale. It might be helpful to an individual in a performance review, but it doesn’t say why X is unnecessary in this project or at this company. Little is added to the discussion until I describe X relative to the goal.

Perfectionism is indeed good to avoid—it's basically defined as a bad thing by being "too". But the better conversation says how X falls short on certain measuring sticks. At the very least it actually engages X in the X discussion. Perfectionism is more of a critique of the person.

This takes work, which is why it tends to signal lazy dismissive arguments. It takes effort to understand the person's idea enough to engage it, but more importantly it takes work that was supposed to (but might not) have gone into developing good projects or goals in the first place. Projects well-formed enough to create constraints for themselves.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: