[part 3]
几个星期前，我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》的中文版 《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了中文版，也有一些感想如下。
Kapor 的团队看起来非常重视“远景”， 他们似乎没有近忧 - 这也许是致命的。
他们对于软件的基本架构/infrastructure 非常关心，例如对于存储系统，它们提出了下列需求：[p103]
- it has to make life easy for the Python programmers
- it has to operate efficiently over a network
- it needs to be able to handle very large individual date items and very large numbers of items
- it has to be reliable, using database "transactions."
- it has to support searching and indexing
- [0] User experience //Kapor 后来加上去的，似乎不相干的一条远景。
后来对于Data Storage，又有如下构想：[p109]
- Provide programmers with as revolutionary a data model as users
- data can live anywhere.
- Data is safe from corruption.
- Data is quick to get.
- Data can be large.
非常令人佩服的远虑。 如果一个项目能同时实现其中3个目标，就已经能实用并吸引客户，开始赚钱了。 但是Chandler 项目的同志们不满足于只实现两三个，他们要实现全部5个梦想。
一群牛人在 “没有近忧，只有远虑” 的条件下讨论问题，最后只能议而不决。 在一次次延续到深夜的讨论中，有人感慨 - "How is this night different from all other nights?" //[p110]
没有近忧，或者说不用为近忧而负责 - “我们这个月的目标没完成不要紧，但是我们的远景一定要讨论好”。 导致了项目不能收敛 - 一个项目的一个里程碑中，不确定的事情应该越来越少，bug 也越来越少，直到产品发布。
Making firm technical choices was hard in the absence of a settled design, and settling on a design was hard in the absence of a technical roadmap. [p150 - 151]
正因为大家没有近忧，所以大家可以继续等待，设计要等技术决定后才好做，而技术的选择要等设计决定后才好开始。就这样，大家折腾到2005年的时候，他们才从高瞻远睹的远虑的云端中下来，有了第一个脚踏实地的计划：
But for the first time, at least, they could see they had a plan grounded in reality, rooted in estimates that ... [p232]
Kapor 毕竟是聪明人，很多年以后，他说到了教训：
We've consistently overinvested in infrastructure and design... [p342]
收敛的另一个特点是 - 做过了的决定，就要执行，不要反复。事实上，Chandler 团队在很多决定上摇摆不定。 架构师Hertzfeld 度假回来，发现他带领其他同事奋战一个夏天得到的 Document Architecture 被扔到一边，原来 Kapor 决定 “We'll have to come back and realign things” [p168]。 如果你是做义务劳动的 Hertzfeld，你还能做下去么？
回到 “远景”， 我相信几乎没有合适的解决方案能满足“远景” 中的所有要求，很难找到 “多快好省” 的解决方案（书中提到 fast|cheap|good 不能兼得，这也是MSF 中 time | resource | feature 三个元素的矛盾）。但是往往存在若干方案，从不同的角度逼近最优，但是有各自令人讨厌的缺点。我们能否有智慧来选择这样一个方案，把近忧，远虑都慢慢解决？
我自己在微软正在做一个创新项目，前几天一位加入这个项目不久的优秀的开发人员对我说，我们去年设计的数据库问题太多了，如果我们早就像我这样设计，估计会好很多。我不是数据库的专家，我只能对他说，如果我们当时坚持要做到今天这样才发布，这个项目也许就做不到今天了。
换句话说，正是因为早期那些不完美，但是及时的设计，让后来者有挑剔这些不完美的奢侈机会。
我们每个人在使用这些不完美的软件（Windows, Outlook, 甚至Linux）的时候，都应该感谢当初设计者做出了正确决定，而那些坚持完美设计远景的项目，它们都到哪去了？