完整评论:
http://yishan.cc/blogs/xin/archive/2008/11/18/iii.aspx
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)的时候,都应该感谢当初设计者做出了正确决定,而那些坚持完美设计远景的项目,它们都到哪去了?
读后感(III)远虑和近忧
《梦断代码》热门书评
-
Dreaming In Code
66有用 0无用 g9 2007-02-14
当年Lotus Development的创始银,Lotus 1-2-3的设计者Mitchell Kapor,离开Lotus后拉开单干,成立了开源应用基金会(OSAF)。他招募了一堆牛程,开发号称革命性的下一代个人信息管理系统--Chandler。我还记得Mitchell Kapor宣布要开发Chan...
-
外国大牛也不过如此
37有用 7无用 庄表伟 2008-09-18
花了一周的时间,看完了《Dreaming in Code》(梦断代码),看得我心潮起伏。对里面那帮家伙的评价也起起落落。最终的结论是:外国大牛也不过如此。别看他们名头那么响,做了那么多超有名的项目,实际的能力(软件开发能力与项目管理能力)看来相当有限。感想很多,想到一点说一点吧。1、以前有一篇文章叫...
-
开源的路在何方?
25有用 1无用 kimi 2008-12-26
在图书馆的阅览室看了这本书,花了我两个小时的时间,午后的阳光透过图书馆的玻璃照进来,很温暖,可是我的心却一点点的凉了下来。 再过半年我,一个计算机系的学生,就要投身到软件开发这个行业中去了,可没有任何经验,仅凭着那些薄弱的理论知识。边看书边记下自己的想法...
-
有关软件工程的焦油坑
16有用 0无用 大徐 2008-09-25
结婚前夕我请假一天,躺在床上看了大半的《梦断代码》,Chandler项目时间从2002年转眼到了2004年,10月26日OSAF发布了 Chandler0.4版。2年时间里,整个项目组的人员从几人上升到了20多人,有人离开,更多的是新人加入。做为一款致力于“无地窖式数据处理”的开源PIM软件,项目组...
-
一身一身的冷汗啊
13有用 1无用 铁观音加枸杞 2008-09-30
这本书看了已经一半多了,就看完的这些部分说点自己想说的。开始看的时候,还是很轻松很调侃的在看老外大牛们的囧事。可是越看越发现这个项目里的很多扯淡的事情其实每天都发生在自己的身边。冷汗啊,一身一身的出,想想以前的很多事情,那真是不停的后怕。 &...
书名: 梦断代码
作者: Scott Rosenberg
出版社: 电子工业出版社
原作名: Dreaming in Code
译者: 韩磊
出版年: 2008.06
页数: 336
定价: 49.00元
ISBN: 9787121066795