90-90法则是贝尔实验室的Tom Cargill所提出的，内容是：开发软件时前90%的代码要花费90%的开发时间，剩余的10%的代码要再花费90%的开发时间。这倒是应了中国一句古话，西汉的刘向说的，行百里者半于九十。看起来软件开发并非是异于其它领域的特殊行业，只是它的从业者们常常做出一些更令人惊讶的事情来。这往往会导致“最终交付时间”远远大于预计时间的180%，但是说完成了却仅花了很短的时间。这里面比较经典的应该是早些年IBM顾问说华为的一句话：有时间改bug没时间把代码写好。

我见过很多关于“完成”的场景，比如说：xx已经完成了，只是还不能用，又比如：程序员说xx现在已经可以对接了，其实代码连完整的集成测试都还没有做过，上面这些例子在我身边都是反反复复出现过的，但是又无可奈何，甚至说深受其害。遥想第一次被坑，好像是花了2天呕心沥血写了600行代码处理一个非常复杂的分页处理，有类似于标题如果在最后一行则跟正文一起移动到下一页、分栏之后左右要对齐之类的各种规则，再加上调试一共花了有一周时间才“完成”，这引起了部门经理的不满，因为另外一个程序员在另一个产品里的类似功能只用了一天就“完成”了。当然，不出意外的是我的代码再往后几乎没有修改，另一个产品的这个功能不断出现问题每个版本都要有人跟那段代码斗争。

*** 很显然，在我的定义里，“完成”的概念是可以交付，而不是可以开始调试。 ***

如果大家认为，最终我用事实证明了自己，那么我只能说，童话散场了，大家可以醒来回家了。毫无悬念地部门经理认为我处理的需求“简单”，所以才bug少，另外一个产品中的需求复杂，所以才会导致bug多。是的，我见过的大部分管理者都是这样的，救火永远比防火重要，到目前为止我做的每一个高质量的系统都被认为是“简单的”。甚至在很多公司都有种说法教导码农要在写代码的时候自己埋雷进去，然后等出事之后自己再解决掉，这才容易升职加薪，我不知道有多少人真的这么做，或者仅仅是拿来调侃，但是这足以说明写代码的尴尬境地。

不管是程序员还是管理者都应该重新考虑一下“完成”的定义，一个恰到好处的“完成”是一个利益最大化的结果，它会让你的组织从这个需求获得理想的结果，更低的成本或者是更高的售价。如何达到一个恰到好处的“完成”是个很有挑战的事情，挑战在于：一、由于没有接受过良好的训练或者因为以往工作压力导致的低质量的完成，是几乎不可逆的损害，大部分人在进入职场之后几年内就失去了学习能力，三岁看老，工作三年也差不多决定了整个职业生涯，所以大部分码农已经失去了用更长时间写出更高质量的代码的能力。二、管理者基于本能的管理对组织风格的影响更加深远，而改变管理者的理念是比改变新人更困难的事情。

这并不是说这个问题无解了，我觉得这反而是更好的机会，给那些更有勇气的人准备的。你懂的～

[每天一个知识点]16-软件工程-什么叫完成