小处着手更容易成功
引：本文是半年前收到《梦断代码》样书后写的书评。我很高兴自己作为行业外人士也能看懂，尽管韩磊说有过项目经验的人会更能理解书中所讲的那些事。
期待了半年，终于看到韩磊的译作《梦断代码》完成了。收到样书一口气读完，诸多感慨，就像韩磊说：真正开发过软件的读者会对书里面写的东西感同深受。包括那些故事，每一个细节，都是自己经历过的，甚至每一句话，都是自己说过或者听别人说过的。这个感觉很奇妙像那个关于Spec的故事（摇滚电影那个），“就在这里，写明了的！”特别能引起共鸣。
作者Scott在扉页所慨叹：为什么好软件如此难做？拥有所有最好的资源、“万事俱备”的Chandler项目的开发历程却如此痛苦艰难——
“两打程序员，三年，4732个bugs，和对非凡软件的不懈追求”。Chandler项目的开发者Mitchell Kapor算是当代最牛的程序员兼管理者之一，招募了一群最牛的开源干将，他们不缺钱、不缺技术和经验，偏偏不能发布这一款看似简单的软件。梦想太过瑰丽和宏伟，最终只会导致更加顽固和自负地把饼无限摊大却无法消化，所有参与者都痛苦不堪。用Scott的话说，“没有人－哪怕是作者－可以全身而退”。
为什么？
从一开始时的简单需求——“用户应该能方便地共享信息”——很快扩张成一大团难题之云。虽说暂时可以推到“以后再说”，但每个人都知道，最终还得设法解决这些问题。
普遍认为重写一个程序要比看别人的快，这是程序员的通病。但别人的东西往往经过经年使用并反复验证，你或许写出一个类似的东西，但最后很可能会被潜在的Bug淹死。如果太过在意过往那些软件灾难留下来的教训，就一行代码也写不下去，项目的要求会不断膨胀超出了此时技术和人力的极限，随之产生的巨大压力会给参与项目的所有人带来心理上的无法弥补的重创。
比如，几乎所有软件工程课本都会讲到的IBM那场空前绝后的软件灾难——美国航空管理局（FAA）1981年上马的AAS项目（Advanced Automation System）。在花费数十亿美元、历经13年、耗尽数千人的心血后颗粒无收，FAA的需求远远超过人类和机器的工作能力，项目成员们被挫败感而不是工作负担压垮，有人砸烂自己的汽车，有人发疯，有人自杀身亡。一位项目经理甚至吃纸上瘾，随着进度一再延误，开会时往自己胃里塞的纸片越来越大。
每次失败都如此相似，简直令人遍体生寒。
Chandle项目也一样。Kapor希望Chandler易于使用，他也希望它能解决一些著名的软件难题，而最后，只能深深地落入折中的困惑，两者都想要。就像佛里德里克·布鲁尔斯在《没有银弹（No Silver Bullet）》中所说的那样：“构建软件系统最难的就是精确设定要做什么东西。”历数Chandler中修正Bug等类似不可知因素，加起来就成了开发经历的噩梦：日程中的“黑洞”，充满不确定性甚至不可知因素的时间陷阱。
也许，就像Linux所说：从小处做起更容易成功。
如果你什么都想要，最后什么也得不到。
应了那句老话，十月怀胎，欲速不达。
例如：沃德.坎宁汉的wiki之所以能问世，不是因为程序员本来就要做一套谁都要添加的网页程序，他只想让协同者能够自行修改错误罢了。
又如：软件公司Ludicorp设计了一套“大规模多用户在线角色扮演游戏”的原型系统，这个叫做Game Neverending的项目很快寿终正寝，但其创建者们用它的一部分修修改改，搭建了Flickr相片共享服务，成为2004年的大热网站（05年被雅虎收购）。
虽然你可能会说这只是种瓜得豆的世间常情而已、是项目开发的意外结果、偶然的成功而已。但是如果一个项目没有种种常规约束，设计蓝图过于宏大，很难逃脱不断延误、混乱、灾难的终途。
软件项目难以按进度安排实现，这种情况极为常见，而且为众人所宽容。在软件项目管理中存在一种充满讽刺意味的天性，尽管程序员工作时所用的计算机和程序语言都要求精确缜密，然而项目进度却如同魔比乌斯环一样时快时慢变幻莫定。正如本书第11章讲述的停机问题值得每一个人深思：
每个软件项目的参与者在开始寻求工作终点时都会一头撞到停机问题的真实版本上，而每个团队都会学到同样痛苦的一课：世上没有能够告知项目何时结束、是否达到目标的简单可靠的规程。正如Alan Cooper在其凌厉之作《精神病患管医院》中写到：软件开发缺少一个关键元素——理解什么是“完成。”
停机问题在Chandler项目的真实反映使得开发者们与之对抗三年之久，到最后只出到0.7版但仍无法使用。通常来说，财务紧缩及资方要求是项目的强制“终结条件”，而纯开源项目的进展只受志愿者投入力量的消长所制约。Chandler坐在两种模式不同寻常的终点处，没有清晰标示“完成”时刻，甚至没有指出何处是可能的终点。
在《梦断代码》的最后一章中，Scott不断追问：我们为什么不能像造桥那样做软件呢？
发问者总在梦想一种基于可信公式的严格规程，但是，没有人能讲出秘诀、开出良方，软件开发的种种技术困难还是在持续的改进前步步败退。
机器越来越复杂，软件开发注定没有通用标准可以依照，我们无法想造桥那样造软件。但仍有一些办法是我们控制的。
对于总有工要赶，整天面对堆积如山开发任务的知识工作者，《Get things done》大师戴维艾伦也谈过困扰他们“恼人焦虑感”：“完成”的定义，即便是对于临时版本或小里程碑也时常是主观武断的，在这一点上，他们的工作更像是作者，而不是修建者。“完成”通常并不显而易见，需要你自作主张的决定。
也许这也是小处着手更容易成功的原因之一，更容易控制，稍容易判断何时完成，何时停止。从这一点来讲，《梦断代码》留给我们一条宝贵的经验：狗食版应从小处做起，由几个专注于此的人来做。
简单专注，知易行难。
但我们一直在坚持，一直在努力。
作者Scott Rosenberg在扉页中写到：“我期望程序员喜欢这本书，但本书对其他人也不无益处。”虽然对于故事的部分程序员更容易体会一些，但对以其他读者，偏理论、历史的章节也是很好的启蒙资料，能让你对软件、软件历史、软件工程、方法论等等有一个全面的认识，而这些也正是本书的精髓。合上此书，相信每一个人都会从那激情澎湃又细致入微的记述里得到诸多感悟，而且也会和我一样悄悄地说：这是一本相当不错的好书。
期待了半年，终于看到韩磊的译作《梦断代码》完成了。收到样书一口气读完，诸多感慨，就像韩磊说：真正开发过软件的读者会对书里面写的东西感同深受。包括那些故事，每一个细节，都是自己经历过的，甚至每一句话，都是自己说过或者听别人说过的。这个感觉很奇妙像那个关于Spec的故事（摇滚电影那个），“就在这里，写明了的！”特别能引起共鸣。
作者Scott在扉页所慨叹：为什么好软件如此难做？拥有所有最好的资源、“万事俱备”的Chandler项目的开发历程却如此痛苦艰难——
“两打程序员，三年，4732个bugs，和对非凡软件的不懈追求”。Chandler项目的开发者Mitchell Kapor算是当代最牛的程序员兼管理者之一，招募了一群最牛的开源干将，他们不缺钱、不缺技术和经验，偏偏不能发布这一款看似简单的软件。梦想太过瑰丽和宏伟，最终只会导致更加顽固和自负地把饼无限摊大却无法消化，所有参与者都痛苦不堪。用Scott的话说，“没有人－哪怕是作者－可以全身而退”。
为什么？
从一开始时的简单需求——“用户应该能方便地共享信息”——很快扩张成一大团难题之云。虽说暂时可以推到“以后再说”，但每个人都知道，最终还得设法解决这些问题。
普遍认为重写一个程序要比看别人的快，这是程序员的通病。但别人的东西往往经过经年使用并反复验证，你或许写出一个类似的东西，但最后很可能会被潜在的Bug淹死。如果太过在意过往那些软件灾难留下来的教训，就一行代码也写不下去，项目的要求会不断膨胀超出了此时技术和人力的极限，随之产生的巨大压力会给参与项目的所有人带来心理上的无法弥补的重创。
比如，几乎所有软件工程课本都会讲到的IBM那场空前绝后的软件灾难——美国航空管理局（FAA）1981年上马的AAS项目（Advanced Automation System）。在花费数十亿美元、历经13年、耗尽数千人的心血后颗粒无收，FAA的需求远远超过人类和机器的工作能力，项目成员们被挫败感而不是工作负担压垮，有人砸烂自己的汽车，有人发疯，有人自杀身亡。一位项目经理甚至吃纸上瘾，随着进度一再延误，开会时往自己胃里塞的纸片越来越大。
每次失败都如此相似，简直令人遍体生寒。
Chandle项目也一样。Kapor希望Chandler易于使用，他也希望它能解决一些著名的软件难题，而最后，只能深深地落入折中的困惑，两者都想要。就像佛里德里克·布鲁尔斯在《没有银弹（No Silver Bullet）》中所说的那样：“构建软件系统最难的就是精确设定要做什么东西。”历数Chandler中修正Bug等类似不可知因素，加起来就成了开发经历的噩梦：日程中的“黑洞”，充满不确定性甚至不可知因素的时间陷阱。
也许，就像Linux所说：从小处做起更容易成功。
如果你什么都想要，最后什么也得不到。
应了那句老话，十月怀胎，欲速不达。
例如：沃德.坎宁汉的wiki之所以能问世，不是因为程序员本来就要做一套谁都要添加的网页程序，他只想让协同者能够自行修改错误罢了。
又如：软件公司Ludicorp设计了一套“大规模多用户在线角色扮演游戏”的原型系统，这个叫做Game Neverending的项目很快寿终正寝，但其创建者们用它的一部分修修改改，搭建了Flickr相片共享服务，成为2004年的大热网站（05年被雅虎收购）。
虽然你可能会说这只是种瓜得豆的世间常情而已、是项目开发的意外结果、偶然的成功而已。但是如果一个项目没有种种常规约束，设计蓝图过于宏大，很难逃脱不断延误、混乱、灾难的终途。
软件项目难以按进度安排实现，这种情况极为常见，而且为众人所宽容。在软件项目管理中存在一种充满讽刺意味的天性，尽管程序员工作时所用的计算机和程序语言都要求精确缜密，然而项目进度却如同魔比乌斯环一样时快时慢变幻莫定。正如本书第11章讲述的停机问题值得每一个人深思：
每个软件项目的参与者在开始寻求工作终点时都会一头撞到停机问题的真实版本上，而每个团队都会学到同样痛苦的一课：世上没有能够告知项目何时结束、是否达到目标的简单可靠的规程。正如Alan Cooper在其凌厉之作《精神病患管医院》中写到：软件开发缺少一个关键元素——理解什么是“完成。”
停机问题在Chandler项目的真实反映使得开发者们与之对抗三年之久，到最后只出到0.7版但仍无法使用。通常来说，财务紧缩及资方要求是项目的强制“终结条件”，而纯开源项目的进展只受志愿者投入力量的消长所制约。Chandler坐在两种模式不同寻常的终点处，没有清晰标示“完成”时刻，甚至没有指出何处是可能的终点。
在《梦断代码》的最后一章中，Scott不断追问：我们为什么不能像造桥那样做软件呢？
发问者总在梦想一种基于可信公式的严格规程，但是，没有人能讲出秘诀、开出良方，软件开发的种种技术困难还是在持续的改进前步步败退。
机器越来越复杂，软件开发注定没有通用标准可以依照，我们无法想造桥那样造软件。但仍有一些办法是我们控制的。
对于总有工要赶，整天面对堆积如山开发任务的知识工作者，《Get things done》大师戴维艾伦也谈过困扰他们“恼人焦虑感”：“完成”的定义，即便是对于临时版本或小里程碑也时常是主观武断的，在这一点上，他们的工作更像是作者，而不是修建者。“完成”通常并不显而易见，需要你自作主张的决定。
也许这也是小处着手更容易成功的原因之一，更容易控制，稍容易判断何时完成，何时停止。从这一点来讲，《梦断代码》留给我们一条宝贵的经验：狗食版应从小处做起，由几个专注于此的人来做。
简单专注，知易行难。
但我们一直在坚持，一直在努力。
作者Scott Rosenberg在扉页中写到：“我期望程序员喜欢这本书，但本书对其他人也不无益处。”虽然对于故事的部分程序员更容易体会一些，但对以其他读者，偏理论、历史的章节也是很好的启蒙资料，能让你对软件、软件历史、软件工程、方法论等等有一个全面的认识，而这些也正是本书的精髓。合上此书，相信每一个人都会从那激情澎湃又细致入微的记述里得到诸多感悟，而且也会和我一样悄悄地说：这是一本相当不错的好书。
有关键情节透露
