I always try to keep in mind that <i>A Mess is not a Technical Debt</i>[1], and that when you keep that in mind you can do it intentionally[2]. Which is particularly useful when you are more interested in learning[3] about a problem (like building a MVP) than when you are in solving it[4].<p>[1] <a href="http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-not-a-technical-debt" rel="nofollow">http://blog.objectmentor.com/articles/2009/09/22/a-mess-is-n...</a><p>[2] <a href="http://martinfowler.com/bliki/TechnicalDebt.html" rel="nofollow">http://martinfowler.com/bliki/TechnicalDebt.html</a><p>[3] <a href="http://www.ashmaurya.com/2011/06/your-product-is-not-the-product/" rel="nofollow">http://www.ashmaurya.com/2011/06/your-product-is-not-the-pro...</a><p>[4] <a href="http://www.threeriversinstitute.org/blog/?p=251" rel="nofollow">http://www.threeriversinstitute.org/blog/?p=251</a>
Insightful article and really well written.<p>I guess the closest you can come is:
- having people around you who have similar standards
- a culture of constantly questioning everything
- a business unit that understands the importance of overcoming tech debt
great article. everytime i need to do a hack, i ask myself the same question. the point of no return moved far away with more coding-experience.<p>i think this is a problem of a perfectionist :)