原文地址：http://www.codinghorror.com/blog/archives/001313.html

    我对我每一个发布过的软件都不满意。因为我和很多开发人员一样是一个完美主义者。会有一些不可避免的问题：

• 日程太紧张了，我们需要更多的时间！
• 我们遇到了未料到的技术问题，不得不妥协
• 我们的设计有问题，不得不在开发之中来改进
• 成员之间出现了我们不希望看到的分歧与摩擦
• 客户和我们之前想象的不同
• 设计师，开发人员，项目组之间的沟通并不很有效
• 我们乐观估计了学习新技术的速度
• ...

列表将会继续，软件项目失败的原因多如牛毛。

软件开发周期的尾声，结束的是一个苍白影子般的软件，开始时你设想的光荣的里程碑。

（At the end of the development cycle, you end up with software that is a pale shadow of the shining, glorious monument to software engineering that you envisioned when you started. ）

在这点上，人们很容易认输--增加时间以完成软件开发。因为，毕竟，真正的开发人员发布。

我告诉你，这是一个错误。

的确，项目中你已经犯了很多的错误。但是同时，在你没发觉的地方，你一样犯了很多错误。这些错误只有在发布了这个版本，并且已经在用户和客户面前的时候才能发现。我认为Donald Rumsfeld 所言极是：

如我们所知，

有了解的事情，

有我们知道我们知道的事情，

我们也知道，

有我们知道的未知，

就是说，

我们知道有一些事情，我们不知道。

但是有一些不知道的未知，

有些事情，我们不知道我们不知道。

面对不可避免的项目尾声的 blues -- 充满妥协，权宜之计--你可以坐下来舔舐你的伤口。你可以在发布（release）之前重新组织，并且用几个月时间来修补这个版本。你可能会对自己感觉很好--这个决策使得世界上少了一个充满 Bug 的软件。

不幸的是，这比发布一个有瑕疵的版本更错误。

不要在一个无菌的，封闭的实验室花费三个月，你可以用三个月时间来听取真实世界的真正你的用户的反馈。软件和用户不是在你的想象之中，而是在存在于现实生活之中。你可以转过来，直接利用这些，真实世界的反馈不仅仅修正了第一个版本的糟糕之处，而且一用户数据为基础，使得你的开发预支更加有效。

前面，我不是再说你应该发布垃圾。相信我，我们都是完美主义者。但是真实的世界对完美主义是残酷的，无情的。随它去吧，并且当你发现你的软件在现实世界崩溃了，失望不可避免...但是这是可以修复的！软件的最初版本的状况并不是那么重要，--事实上，有人说如果你没有被 v1.0 折磨，你就是没有足够早的发布它--但是，在软件发布之后你在做什么呢？

你的团队对用户反馈的相应及其速度将会确定你的软件的品质，比任何一个发布都重要。这是你需要擅长的。不是柏拉图式的完美的软件，而是响应你的用户，你的客户，通过他们的反馈持续的改进你的软件。所以，你在为接近完美的软件发布做优化，你就是做错了事情。

毫无疑问，你要尽可能早的发布软件，然后根据现实世界的反馈快速迭代。

相信我：尽管 版本1 很糟糕，发布它。