时间和交流：时间对每一个人都是公平的，对每一个软件项目也是这样。
正如书中所说的：“nearly all software projects require only 1/6 of their time for the writing of code and fully 1/2 of their schedule for testing and fixing bugs. But it was rare project manager who actually planned to allocate developers’ time according to such a breakdown. [p17]。”
书中援引理论家的话说，最高效的软件团队规模应该是一个人，因为这样就不用交流了。 随着人数的增加，依赖关系的复杂，新手，老手员工之间的不同步，交流的成本会随着几何级数增加。在这里插播一个有奖竟猜：
当Windows 研发团队在开发Windows 2000的时候，团队内部每天有多少封e-mail 交流？
a) 90
b) 900
c) 9,000
d) 90,000
对每一个团队成员来说，他/她不仅要完成手头工作，还有报告自己的进展（通过email 或其他形式），回答别人的问题，了解其他人的进展。每个人的时间都是有限的，那怎么能保证我们在应付所有的交流/沟通之后，能有时间完成“手头工作”？
外部交流
在Chandler 项目中，幸运的是，他们没有这么多VP 要汇报 （真正的VP – Al Gore 只露了一个小脸），但是我注意到他们用于交流的时间也非常多。例如：
Every day the developers shared a chat room via Internet Relay Chat (IRC) [p139]
1 internal and 4 external email list set up.
blogs, wiki’s…
这些都是花时间的！我看到团队成员还要回复素未谋面的爱好者的各种问题（例如质问他们为何不用某某框架，等等），当然这种透明度也满足了很多人的好奇心，开源，社区的优点么。。。 另一方面，项目管理人员发现他们面对着大量的任务没有时间完成。就像第一章 Doomed 的开篇就说到：
John is doomed, he has 500 hours of work scheduled between now and the next release… [p11]
团队中其他人也好不到哪里去。那在这种情况下，是花时间继续参加各种讨论，blog，提供透明度 （Transparency），满足大众的好奇心，还是集中精力把自己“手头的事” 搞定？我从书中没有看到经验丰富的管理人员这时候采取了什么措施。事实上，在产品发布之后，没有证据表明，那些在IRC，Email，BBS 上发了很多议论的爱好者未必真正下载并使用你根据他们的意见开发出来的软件。那这么忙于交流是为嘛?!
事实上，这么多交流和信息并不能帮助人们回答一个最重要的问题 –
What had each programmer accomplished in the past week, and what task was next? [p141]
内部的交流
除了外部的交流，还有内部的交流，随着一个人经验的增多，会有很多其他人来找你，为大大小小的事咨询你的意见。然而你自己也有无数的任务要完成，怎么办？微软的员工对这种情况也不陌生，微软团队允许一些人 “Go Dark”，他们可以关起门自己干活，敲门不答应，不回答一般的email，不参加会议等等。
据说很早以前，BillG 把开发OS/2 API 的任务交给了一个牛人，这位前辈接受任务之后，并没有开新闻发布会，建立email distribution list, 或者QQ 群，而是挂了一个和下面类似的牌子在办公室门外，把门一关，一个人闷头开发去了。
不要打扰、投喂办公室里的动物
我们知道交流很重要，但是软件不是在QQ 群中交流出来的（当然，有人在QQ 群中交流别人写好的软件），而是一些人一行行写出来的。 这个过程需要集中注意力，避免打扰。在一个 “集市” 风格， “共享” 的开发氛围中，如何能保证关起门来开发呢？
远虑和近忧
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）的时候，都应该感谢当初设计者做出了正确决定，而那些坚持完美设计远景的项目，它们都到哪去了？