为何程序员完成最后20%的工作需要的时间跟之前的80%一样多？

听过行百里者半九十吧。这句话在程序员的工作中同样适用，到底是为何呢？Matija用一个精巧的比喻揭示了个中道理。

其实这就好比在高峰期从郊外开车回市中心。前 80% 的路程很顺，高速嘛，可能两小时就走完了，但是到了城里，就走不动了，红绿灯，人行道，各种环线和菜鸟司机，可能两个小时还不够用的。

编程也是如此。最开始你要设计框架，给整个项目打基础，然后开始开发，几周或者几月之后，你完成了整个项目 80% 的工作，各种关键模块开始起作用了。

但是好戏才刚刚开始，当你准备好好打磨这款产品时，就会发现许多奇怪的 bug 冒出来了。比如：“喂，你知道这个程序在读取文件时拔掉 USB 线会崩溃么？”，“看起来是程序不想下载文件名里有感叹号的文件...”

这个时候，如果管理层下令要尽快搞定这剩下的 20% 的话，开发团队就得弃掉汽车，徒步越过最后几个障碍，只求按期到达地点，把车丢那不管了。也许能够按期完工，但是这种办法并不明智。

这篇文章被贴到 HN 上之后，引发了众网友的热烈讨论，大家纷纷表示感同身受。有一位朋友贴出了 Quora 上一个很精彩的问答：“为何软件开发的实际周期总是比预期的要长两三倍？”排位第一的回答真心机智幽默。

简单的说是这样的，软件开发同徒步旅游一样，可能你最初是计划在 10 天内走完 500 公里，但真走起来，你会发现路上碰到的问题层出不穷，每天走的里程数都在递减，团队士气也不太稳定，延期很多时候都是无可避免的。

其实何止是软件开发，做任何一款产品的历程大都如此。硬件项目也是做出原型简单，真正量产时会碰到各种问题，需要你耐下性子一个个解决，有时还得不断返工。魔鬼在细节中潜藏，要想达到尽善尽美，就得花额外的精力去雕琢那最后 10% 的部分。