Ask HN: How to convince my coworkers to ship imperfect code?

We’ve heard mantras many times. Mark Zuckerberg urges to „Move fast and break things” ( although it’s „move fast with stable infrastructure” now. ). Reid Hoffman says, that „If you are not embarrassed with first version of your product, you are too late”. And in my company, we are buying in the adage of moving fast.<p>In the trenches, close to the code, perfectionism is chipping away at our productivity.<p>&quot;Let’s take time to make this piece future-proof because we never get around to refactoring things later”. The motivation is noble - save ourselves and future victims of our code some problems. But, what I’ve seen is: - We never get around to refactoring because we take SO MUCH time honing v1 that nobody sane gives us more time to make it better. Maybe if we shipped sooner, we could refactor later? (That is my personal experience when I just wanted to refactor) - We spent days making some solution perfect but it turns out the whole data structure is useless and has to be thrown away because it just does not fit to overall infrastructure. - That making perfect blocks other people from iterating on it.<p>I found out that following approach works best<p>1 Hack together an end - to - end prototype to test if all pieces can work together in the hackieshest way possible 2 Design interfaces between the pieces 3 Extract classes, libraries, etc so improvements are easy to collaborate on 4 Ship MVP to production to get user feedback 5 Introduce every non-critical part of the feature while taking user feedback into account<p>Perfectionism is something that is plaguing authors and other professionals ( Although I hate „code is poetry” adage, I do see shared struggle between coders and authors and a lot of advice can be inferred from books like „Bird By Bird” by Anne Lamot - especially concept of „shitty first draft&quot; )<p>Soo… How do I convince my coworkers to iterate more? Ideally, I’d like to create online perfectionism-antidote. Or am I wrong maybe?