可以计划、策划、分割、折叠、旋转和扭曲一个项目无数个小时，但你仍然不知道在实际编写代码时会遇到的困难。
本篇文章，我将会表达一些略主观的意见：
对于任何具有重要意义的软件项目，准确预估是不可能的。
现在，你们中有很多人读到这句话会认为我疯了。也许我确实疯了，但总得有人说出我们都知道却不愿承认的事实。
关于如何更好地预估软件项目，市面上已经有很多书讨论过，在预估软件项目时也一定举行了很多会议，购买了不少时间的咨询，写了很多博客帖子。我明白，我们都在努力工作，尽最大努力，试图安抚那些想知道新功能何时准备好的老板。我们总是根据会议日期而不是软件实际准备好的时间来设定截止日期。
但实际情况是，我们根本做不到。好吧，我们相信我们可以做到——实际上，我们一直在这样做——但我们做得并不好。换句话说，我们的预估总是有或多或少的偏差。
我的意思是，我们不断地花钱参加研讨会，阅读博客和书籍。我们请来高薪的顾问，他们表现得好像自己知道自己在说什么。但这项工作从未变得更好。我们在这件事上很糟糕，却总是认为我们可以改进，下一个流行趋势真的会是灵丹妙药。但我们不愿承认我们所知道的真相：我们根本无法对软件项目进行非常有信心的估算。
我们都做过这样的项目，我们认为需要一定的时间，但最终却花了两倍或三倍的时间。你可能参与过一个项目，它比预期提前了一半的时间完成。但很少有项目能在原始估算的紧密窗口内完成。然后，当我们应用霍夫斯塔特定律（“它总是比你预期的要长，即使你考虑到霍夫斯塔特定律”）并将估算时间加倍时，往往最后预估时间还是有偏差。
这种情况发生的原因有几个。最突出的，我认为也是大多数人最难接受的，是每个软件项目都是独特的，它有自己长长的“未知的未知”清单。你可以计划、策划、分割、折叠、旋转和扭曲一个项目无数个小时，但你仍然不知道在实际编写代码时会遇到的困难。一些你认为具有挑战性的事情最终可能很容易解决。但大多数时候，你会严重低估项目某个特定方面所带来的挑战。
当然，这种情况发生的原因是，大部分的软件经理总是相信所走的路径将是一条平坦、笔直的高速公路，一路上天气都很好。而事实永远不是这样，需求会不断变化，这些变化的需求不会使项目所用时间变短。人们会意外地请假，会受到其他项目或优先事项的干扰，销售部门需要这个小调整来完成一笔大交易。从开始到结束，永远不会一帆风顺。
我有一个拥有计算机工程学位的朋友，当我这么说时，他会非常生气，但真正的问题是，软件开发不是一门工程学科。相反，它是一个和充满了变化的人类欲望相互作用的状态，以及不断变化的客户需求、不科学的解决方案相互斗争的过程。软件开发是一个创造性的过程，而不是一个按部就班程序化的过程，创造性的努力不能被简化为可知的步骤和可重复的系统。
当然，我知道这很难听。企业——我的意思是客户——不想听到“嗯，我们真的不确定什么时候能为你准备好。”他们会选择客户更愿意接受的话来与客户沟通或承诺，即使那完全是胡说八道。公司必须赚钱，为了做到这一点，他们需要尽快产生价值，新功能的演示实际上确实需要在那个特定的会议上发生。
我们需要找到方法接受和适应这一特征。我这么说是因为我认为，作为一个行业，我们一直在寻找软件预估的圣杯，而且我们永远都会这样做，虽然我们永远不会弄清楚。直到我们接受这一点，我们将继续挣扎和挣扎，并继续告诉自己一些我们知道根本不是真的的事情。
我没有解决方案，我怀疑甚至根本就没有解决方案。接受这一点是解决问题的第一步，这个问题永远也不会消失。
原文标题：Why we suck at estimating software projects
原文作者： Nick Hodges
