这三篇读后感原来发布在我自己申请的域名 yishan.cc 上面，后来这个域名被墙了。
（原文写于2008年12月）
几个星期前，我给《现代软件工程》课的每一个团队都发了一本 《Dreaming In Code》的中文版 《梦断代码》，要求写读后感。这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。我是9月份读的英文版，后来又翻阅了中文版，也有一些感想如下。
1）驱动
到底是什么驱动程序员和管理人员，测试人员长年累月投入到一个软件项目中去？
有理论认为，传统的软件公司用工资，职位，绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作（大教堂/Cathedral模式）。其实，用开源，社区，共享的模式会更好（集市/Bazaar模式）也许更好。正如在第26页所说的 [所有页码都是指英文版]
… it maps an alternate universe for programming in which time is simply less important because the work is cooperative rather than corporate, the workers are all volunteers, and the motivation is fun and ego, not financial reward. [p26]
这理论听起来很好，但是我想起了两个故事：
1) 美国的一个肥皂剧Seinfield里有一集，讲了一个混混Kramer 热心地加入了一家公司，义务打工，起初他的口头幽默和热情感动了团队，领导委以重任，不料Kramer 根本没法儿把事情做好。最后领导只好找他谈话，Kramer 承认自己不行，他说- 但是俺是义务给你们打工的！ 领导说，对，这就是让我们为难的地方。。。 项目中来了一位“义务打工的”，照理说，对项目只有帮助，而且别人是“义务”，你怎么好意思把别人赶走？
2) 我以前在西雅图的时候参加过一个非营利组织，成员们都是有热情为社区服务，而且义务付出。但是后来有些成员就逐渐找不到了，一些事情也不了了之。 由于大家都是义务贡献，你没法如何要求别人。
在Chandler 项目中，Andy Hertzfeld 就是这样一个义务作贡献的大牛。但是他也遇到了同样的"志愿者问题" –
They don’t know whether to count on you or not. And because you’re not getting paid, there’s lack of control. [p167]
后来这位Hertzfeld 也拍拍屁股走人了，大家可以为 fun 和 Ego 一起工作，但是如果fun 和 ego 都得不到满足，或者，那motivation 也会急剧下降。
2）责任 和驱动紧密相关的，是责任 – Accountability.
在 Hard Drive 这本书中，讲了这样的故事 – 由于Windows 一再拖延，BillG 最后跟 SteveB 说 – 如果今年下雪之前Windows 还没出来，你就别在这儿干了。 书中没有详细讲 SteveB 回头来又和他的团队讲了什么，但是第二天一个员工背着睡袋进驻了办公室。
很多年以后，Windows Vista 也经历了很长的拖延，在又一次宣布拖延之后，人们发现 Windows 团队中一个赫赫有名的 VP 已经卷起铺盖走了。
我们回过头来看，在Chandler 项目长达7年的拖延中，有没有发生过各位项目管理者引咎辞职的事？ 好像没有。 [有不少人离开，但是没有人直接为项目延期负责] 既然我上一次拖延没有什么惩罚，那我为什么一定要拼了老命要避免下一次拖延呢？
在传统意义上的软件公司，如果项目延期，那项目原计划的收入就拿不到，拖延的时间再长一些，员工就得走人，否则整个公司都被拖垮了。在“集市”，社区，共享的模式下，大家都是义务，大家都在玩票，大家都做贡献，但是对最终项目不直接负责任，那到底谁负直接责任呢？
在《移山之道》 中，我讲了下面的例子：
阿超：我今天在“顶球”网吧看到大牛他爹在下棋，围观者支招的不少，有的说上马，有的说拱卒，有的说出车。大牛他爹一会儿招法就乱了，眼看局势不灵了，围观者一哄而散，老崔后来也没法，只好认输了。
一个围棋国手在一次重要的对局后，听到旁观者对棋局的进程有很多不同的看法，他也没有过多争辩，只是说：“无责任的旁观者和有重大责任的当局者的看法自然是不一样的”。
无责任的旁观者在支招后，如果不灵，他可以面不改色地继续支招，甚至可以给另一位对局者支招，不管最后谁输谁赢，旁观者随时都能安心地离开，回家吃饭。有重大责任的当局者在走了损招或败招之后，他很可能就要认输下台，丢掉比赛的奖金和头衔。
我在清华大学的这一次《现代软件工程》课，我发现有些学生好像不是特别投入，后来了解到，由于申请学校用的GPA只计算前三年的成绩，第四学年课程的分数就和申请学校没有什么关系了，所以比较“鸡肋”。有一个同学说，如果这门课是在第三学期，那许多同学们会非常计较分数，排名。现在，只要能过就可以了。这也许解释了不少项目中出现了“花最少的努力能过就行”的心态。
一个软件团队可以制定出动人的远景/Vision， 但是如果大家没有搞清楚驱动项目的各种因素和每个角色应付的责任，那Vision只是一句话而已。
时间和交流：时间对每一个人都是公平的，对每一个软件项目也是这样。
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 或其他形式），回答别人的问题，了解其他人的进展。每个人的时间都是有限的，那怎么能保证我们在应付所有的交流/沟通之后，能有时间完成“手头工作”？
一个微软的同事前两天跟我说，他们最近没写什么代码，集中精力做“planning” 去了，大家写了很多PowerPoint，改了很多PowerPoint。然后给VP, General Manger 做了两轮汇报，然后根据VP们的意见再修改，再汇报。。。 PowerPoint 的风格变得非常专业和花哨，但是他们仍然没有完成Planning，进入实质开发阶段。华丽的 PowerPoint 中的每一个条目，也需要花PM 很多时间才能写明白，让VP 了解，同时也要花一线dev/test 很多时间才能实现，但是VP，PM 和 Dev/Test 面对同一个条目，他们心里想的是同一回事么？
外部交流
在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]
我的故事 – 在MS Outlook97 发布之后，网上对这个V1 版本有很多意见，也有很多期待。 其中很多用户在 NewsGroup (新闻组) BBS 上发表了强烈的建议，要求Outlook 支持直接阅读 NewsGroup/BBS 的内容，当时只有Outlook Express 有这个功能。Outlook 的开发成员一度认为用户的要求太强烈了，如果我们没有这个功能，可能V2就会很不受欢迎 （几个dev 已经做了一个初始版本）。 但是大家仔细分析后发现，在BBS上强烈发言的，就是那么几个人，因为他们老用BBS，因此他们的需求特别强烈，并且好像声势浩大，但是别的大部分用户根本就不上BBS，因此也没机会表达意见。所以Outlook 决定不做 NewsGroup 的功能，一直到现在。
内部的交流
除了外部的交流，还有内部的交流，随着一个人经验的增多，会有很多其他人来找你，为大大小小的事咨询你的意见。然而你自己也有无数的任务要完成，怎么办？微软的员工对这种情况也不陌生，微软团队允许一些人 “Go Dark”，他们可以关起门自己干活，敲门不答应，不回答一般的email，不参加会议等等。
据说很早以前，BillG 把开发OS/2 API 的任务交给了一个牛人，这位前辈接受任务之后，并没有开新闻发布会，建立email distribution list, 或者QQ 群，而是挂了一个和下面类似的牌子在办公室门外，把门一关，一个人闷头开发去了。
不要打扰、投喂办公室里的动物
我们知道交流很重要，但是软件不是在QQ 群中交流出来的（当然，有人在QQ 群中交流别人写好的软件），而是一些人一行行写出来的。 这个过程需要集中注意力，避免打扰。在一个 “集市” 风格， “共享” 的开发氛围中，如何能保证关起门来开发呢？
远虑和近忧
Kapor 的团队看起来非常重视“远景”， 他们似乎没有近忧 – 这也许是致命的。
他们对于软件的基本架构/infrastructure 非常关心，例如对于存储系统，它们提出了下列需求：[p103]
后来对于Data Storage，又有如下构想：[p109]
非常令人佩服的远虑。 如果一个项目能同时实现其中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）的时候，都应该感谢当初设计者做出了正确决定，而那些坚持完美设计远景的项目，它们都到哪去了？
原文：http://www.cnblogs.com/xinz/p/4298446.html