《梦断代码》
有关软件工程的焦油坑 来自: 大徐
结婚前夕我请假一天，躺在床上看了大半的《梦断代码》，Chandler项目时间从2002年转眼到了2004年，10月26日OSAF发布了 Chandler0.4版。2年时间里，整个项目组的人员从几人上升到了20多人，有人离开，更多的是新人加入。做为一款致力于“无地窖式数据处理”的开源PIM软件，项目组的所有成员似乎经历了软件工程中的一切噩梦。项目的计划不断延后，需求不断变更，技术体系不断调整，功能不断取舍。然而，世界一直在进步，“许多以前为Chandler发布高唱赞歌的外部人员抛弃了它，有些正式参与者认为它迷失了道理“。
2001年，卡普尔办公室外的机房里，放置着一台Microsoft Exchange服务器。“Exchange太过强大，功能远超小机构所需。Exchange也很昂贵：得置办一台服务器、购买Windows许可、购买 Exchange软件许可，如果没有全职技术人员，还得雇个咨询师，请他每月来几个小时作系统调整。在如梦方醒之前，你已经为保持日历同步花费了上千美金。”
人们需要一款超级软件能够帮助自己管理日历、电子邮件、任务、便条……等等个人信息。在2002年到2004年间，微软同样延迟发布了“那个美妙的、听起来与Chandler无地窖式数据处理手段相似的新WinFS文件系统”的发布。但Google发布了Gmail，并迅速赢得了一些用户的欢迎。现在是2008年的9月15日，Gmail发布几年以后的今年，少数人使用并疯狂热爱的现象一直持续到了现在。我身边的同事至少有5人疯狂的使用 Gmail管理日常的邮件和待办事宜，并通过Google一系列的服务完成自己日常的信息管理工作。
Google在Web上的成功好像嘲笑了传统软件行业，但软件工程的诸多问题并没有得到解决。“OSAF工作环境宜人－－午餐很好，工作时间有弹性，气氛非常融洽”。我想象在美国人烟稀少的中小城市的一座几层高的建筑物内，几个人一起密切工作并随时和来自全球的一些志愿者以及关注着在线沟通的情景。想像他们宽大的办公室里跑来跑去的宠物狗以及松散个性的办公桌。想象大家一起喝着咖啡，不慌不忙的讨论着一个又一个的问题的情景。他们几乎不为生计发愁，可以携带家人去国外度假1个月再回来工作。他们每个人几乎都有足够多的技能和经验，甚至某些人还在这个行业内有着举足轻重的履历。整个项目有想法，有钱，有时间，但却失败了。
这让我想起前几个月仅看过开头的《最后期限》，一个梦幻般的开局。富有经验的管理者，足够多的金钱和信任，随便挑选并且足够多的高智商、高能力的开发人员，一个任务甚至可以同时分配给3个开发小组来互相PK。似乎拥有了这一切我们可以作任何项目，开发出任何软件。似乎我们没有理由不成功，我们甚至会想，一定可以干的更好，更快速，更便宜、质量更好！但目前来看，不可能！
看到梦断代码的后半段时，我有一种开练的冲动，想拥有一个自己的工作室或者办公室的冲动。我认为我可以避免他们犯的大多数错误，虽然那些错误我也犯过，或者我曾经经历过的项目犯过。仔细想想其实不然，我现在正在经历的项目已经无可避免的犯了很多书中提到的错误，其中不少是我曾经犯过的错误。我们：
1，想的太多，总想做大事，并且眼高手低；
2，分不清轻重缓急，一上来战线拉的过长；
3，不知道自己到底要做什么，所有人员都陷入迷惘；
4，开会太多，总不干正事，特别是会议缺乏主题和快速达成结论的风格；
5，太多成员缺乏时间计划概念，对自己、对团队成员都没有时间计划；
6，不是缺乏计划就是计划不切实际；
7，需求不断变更并且没有人评估变更对项目整体带来的影响；
8，需求文档不清或者文档过多，产品经理缺乏对产品的构思和描述；
9，缺乏沟通，所有角色人员之间均缺乏有效沟通；
10，过于乐观，无论是领导还是开发工程师，总是过于乐观；
11，项目时间从后向前推，项目计划充满不诚实的欺骗；
12，自上而下的执行方式；
……
随便想想，这里就可以罗列出12条致命的错误，而且这些错误中的大部分我之前都遇到过。有些我有自信可以做好，有些我在发生前可以预知，有些看似没有办法。但这次不一样，我带领一个团队，几个小孩儿，好像并不是那么回事。之前做的几个项目虽然也会很忙，但终究会留下一些文字记录，但这次至今为止写下的文字很少。现在，我有些后悔，从封闭开发到一段时间的放任，到现在的高压，我忙于应付，基本没有留下什么文字记录。我想任何时候开始都不晚，从现在开始，一边记录新发事务，一边回忆并记录。我想找我身边共同经历过整个事情的同事多聊聊也许是正确的，也是应该去做的。
综上所述，我有种感觉，我应该大量记录我的工作情况和我的心理变化，甚至从一个旁观者的角度经常采访我的同事，以便于达到通过不同的角度阐述同一件事情的目的。我开始认为这个项目的经历对我而言非常重要，我需要文字来整理所有遇到的事情。我希望有朝一日有机会将这些文字进行整理，以对我自己和其他人有所帮助，为了达到这一目标，我需要每天抽出至少1个小时的时间来进行写作。
总的来说，这是一个虽然艰难但有前景的项目，是互联网行业和传统电信业的结合的项目。到目前为止已经经历了将近4个月的时间，分别在7月8日和8 月 1日发布了2个测试版本，准备在10月8日发布第一个公开版本。公司中的很多人，包括CEO和市场部的同事都认为我们作出的产品没有任何亮点和竞争力，和他们想象中的相去甚远。他们虽然明白不能一口吃成胖子，但实际的做法确实希望一口吃成几个胖子。
梦断代码的结局有些突然，作者没有再继续跟踪这个项目，但事实上3年的过程记录已经非常有代表性。Chandler项目发布了0.6版本，基本上成为一个可用的“狗食”版，但明显离最开始的目标相去甚远。几年中间已经多次调整过目标，内部和外部的环境也发生了非常多的变化，唯一不变的是软件开发者的精神。看到书中05年整个团队全家福的时候我还是有些吃惊，几年过去了，是什么维持着这个团队？是那几百万美金？是这里惬意的工作环境？是有挑战的工作内容？也许答案就是封面上的那句话，只为打造卓越软件。
可以说，在中国，这样的事情基本不会发生。我们能够承受的时间不会这么长，我们不会不求回报，不求市场化，不求被收购和变现的去长期的做一件事情。我们的工程师也没有机会去休假一个月，相反会每天加班，疯狂工作。我的领导一定会在人手不够的时候考虑快速招人甚至采用外包的形式，整个项目也许会来的快去的也快。总的来说，我觉得我面临的软件工程的焦油坑比那些外国同行们面临的更困难，而我们还经常走一些前人已经走过的弯路，这是更难过的一件事情。
2001年，卡普尔办公室外的机房里，放置着一台Microsoft Exchange服务器。“Exchange太过强大，功能远超小机构所需。Exchange也很昂贵：得置办一台服务器、购买Windows许可、购买 Exchange软件许可，如果没有全职技术人员，还得雇个咨询师，请他每月来几个小时作系统调整。在如梦方醒之前，你已经为保持日历同步花费了上千美金。”
人们需要一款超级软件能够帮助自己管理日历、电子邮件、任务、便条……等等个人信息。在2002年到2004年间，微软同样延迟发布了“那个美妙的、听起来与Chandler无地窖式数据处理手段相似的新WinFS文件系统”的发布。但Google发布了Gmail，并迅速赢得了一些用户的欢迎。现在是2008年的9月15日，Gmail发布几年以后的今年，少数人使用并疯狂热爱的现象一直持续到了现在。我身边的同事至少有5人疯狂的使用 Gmail管理日常的邮件和待办事宜，并通过Google一系列的服务完成自己日常的信息管理工作。
Google在Web上的成功好像嘲笑了传统软件行业，但软件工程的诸多问题并没有得到解决。“OSAF工作环境宜人－－午餐很好，工作时间有弹性，气氛非常融洽”。我想象在美国人烟稀少的中小城市的一座几层高的建筑物内，几个人一起密切工作并随时和来自全球的一些志愿者以及关注着在线沟通的情景。想像他们宽大的办公室里跑来跑去的宠物狗以及松散个性的办公桌。想象大家一起喝着咖啡，不慌不忙的讨论着一个又一个的问题的情景。他们几乎不为生计发愁，可以携带家人去国外度假1个月再回来工作。他们每个人几乎都有足够多的技能和经验，甚至某些人还在这个行业内有着举足轻重的履历。整个项目有想法，有钱，有时间，但却失败了。
这让我想起前几个月仅看过开头的《最后期限》，一个梦幻般的开局。富有经验的管理者，足够多的金钱和信任，随便挑选并且足够多的高智商、高能力的开发人员，一个任务甚至可以同时分配给3个开发小组来互相PK。似乎拥有了这一切我们可以作任何项目，开发出任何软件。似乎我们没有理由不成功，我们甚至会想，一定可以干的更好，更快速，更便宜、质量更好！但目前来看，不可能！
看到梦断代码的后半段时，我有一种开练的冲动，想拥有一个自己的工作室或者办公室的冲动。我认为我可以避免他们犯的大多数错误，虽然那些错误我也犯过，或者我曾经经历过的项目犯过。仔细想想其实不然，我现在正在经历的项目已经无可避免的犯了很多书中提到的错误，其中不少是我曾经犯过的错误。我们：
1，想的太多，总想做大事，并且眼高手低；
2，分不清轻重缓急，一上来战线拉的过长；
3，不知道自己到底要做什么，所有人员都陷入迷惘；
4，开会太多，总不干正事，特别是会议缺乏主题和快速达成结论的风格；
5，太多成员缺乏时间计划概念，对自己、对团队成员都没有时间计划；
6，不是缺乏计划就是计划不切实际；
7，需求不断变更并且没有人评估变更对项目整体带来的影响；
8，需求文档不清或者文档过多，产品经理缺乏对产品的构思和描述；
9，缺乏沟通，所有角色人员之间均缺乏有效沟通；
10，过于乐观，无论是领导还是开发工程师，总是过于乐观；
11，项目时间从后向前推，项目计划充满不诚实的欺骗；
12，自上而下的执行方式；
……
随便想想，这里就可以罗列出12条致命的错误，而且这些错误中的大部分我之前都遇到过。有些我有自信可以做好，有些我在发生前可以预知，有些看似没有办法。但这次不一样，我带领一个团队，几个小孩儿，好像并不是那么回事。之前做的几个项目虽然也会很忙，但终究会留下一些文字记录，但这次至今为止写下的文字很少。现在，我有些后悔，从封闭开发到一段时间的放任，到现在的高压，我忙于应付，基本没有留下什么文字记录。我想任何时候开始都不晚，从现在开始，一边记录新发事务，一边回忆并记录。我想找我身边共同经历过整个事情的同事多聊聊也许是正确的，也是应该去做的。
综上所述，我有种感觉，我应该大量记录我的工作情况和我的心理变化，甚至从一个旁观者的角度经常采访我的同事，以便于达到通过不同的角度阐述同一件事情的目的。我开始认为这个项目的经历对我而言非常重要，我需要文字来整理所有遇到的事情。我希望有朝一日有机会将这些文字进行整理，以对我自己和其他人有所帮助，为了达到这一目标，我需要每天抽出至少1个小时的时间来进行写作。
总的来说，这是一个虽然艰难但有前景的项目，是互联网行业和传统电信业的结合的项目。到目前为止已经经历了将近4个月的时间，分别在7月8日和8 月 1日发布了2个测试版本，准备在10月8日发布第一个公开版本。公司中的很多人，包括CEO和市场部的同事都认为我们作出的产品没有任何亮点和竞争力，和他们想象中的相去甚远。他们虽然明白不能一口吃成胖子，但实际的做法确实希望一口吃成几个胖子。
梦断代码的结局有些突然，作者没有再继续跟踪这个项目，但事实上3年的过程记录已经非常有代表性。Chandler项目发布了0.6版本，基本上成为一个可用的“狗食”版，但明显离最开始的目标相去甚远。几年中间已经多次调整过目标，内部和外部的环境也发生了非常多的变化，唯一不变的是软件开发者的精神。看到书中05年整个团队全家福的时候我还是有些吃惊，几年过去了，是什么维持着这个团队？是那几百万美金？是这里惬意的工作环境？是有挑战的工作内容？也许答案就是封面上的那句话，只为打造卓越软件。
可以说，在中国，这样的事情基本不会发生。我们能够承受的时间不会这么长，我们不会不求回报，不求市场化，不求被收购和变现的去长期的做一件事情。我们的工程师也没有机会去休假一个月，相反会每天加班，疯狂工作。我的领导一定会在人手不够的时候考虑快速招人甚至采用外包的形式，整个项目也许会来的快去的也快。总的来说，我觉得我面临的软件工程的焦油坑比那些外国同行们面临的更困难，而我们还经常走一些前人已经走过的弯路，这是更难过的一件事情。
----------------------------------------------------------------------------------------------------------------------------------
一身一身的冷汗啊
来自: 铁观音加枸杞
这本书看了已经一半多了，就看完的这些部分说点自己想说的。开始看的时候，还是很轻松很调侃的在看老外大牛们的囧事。可是越看越发现这个项目里的很多扯淡的事情其实每天都发生在自己的身边。冷汗啊，一身一身的出，想想以前的很多事情，那真是不停的后怕。
做技术的人，尤其是对技术痴迷的人，遇到一个问题首先想到的不是用户的体验，而是自己在技术上的快感。好像不用点什么新鲜的技术就对不起客户似的。其实呢？其实客户懂什么叫P2P吗？懂什么叫SOA吗？懂什么叫AJAX吗？这些其实都不是用户关心的。用户关心的是什么？用户关心的只是实现！只要能实现客户的业务需求，那用什么技术用什么方式真的有很大关系吗？
在国内做项目，尤其是政府项目，都是关系先行。这种形式其实在某个方面给我们带来很大的好处的。其实大家仔细想想如果每个项目都按照合同的约定来完成的话，我们有几个项目是可以收到钱的？我们又有几个项目是可以不失败的？
客户是上帝。可是我们真的是把客户作为上帝，还是把我们自己的技术欲望作为上帝了呢？
终于把这本书看完了，大牛们的项目也终于失败了。看到后期一直在想一个问题。程序员到底是建筑工人还是艺术家？
现在，国内受印度软件外包模式的影响，认为程序员就是建筑工人。一个完整的程序建立过程就是一栋建筑的构建过程。可是在实际过程呢？我们永远无法准确估计进度，就像我们永远不知道下一个巧克力是什么味道。
“好，没问题，月底肯定能完成！”
“哦！出了点小问题，再有一个礼拜吧？”
“程序已经发到测试部了！有没有问题问测试吧！”
“哦！这个我们没有考虑到等等吧，我们尽快！”
“什么？你什么时候说过这个问题啊？”
工程进度！？好像成了一个谜，而且是一个永远无法破解的谜！无法估计，无法考核。程序员总在认为自己的工作不是在累砖和泥！认为自己在从事一个艺术品，可是谁听说过艺术品还有规定工期和逻辑性的？
所以问题还是绕回到最初，我们到底是在干什么？我是为谁在做？
做技术的人，尤其是对技术痴迷的人，遇到一个问题首先想到的不是用户的体验，而是自己在技术上的快感。好像不用点什么新鲜的技术就对不起客户似的。其实呢？其实客户懂什么叫P2P吗？懂什么叫SOA吗？懂什么叫AJAX吗？这些其实都不是用户关心的。用户关心的是什么？用户关心的只是实现！只要能实现客户的业务需求，那用什么技术用什么方式真的有很大关系吗？
在国内做项目，尤其是政府项目，都是关系先行。这种形式其实在某个方面给我们带来很大的好处的。其实大家仔细想想如果每个项目都按照合同的约定来完成的话，我们有几个项目是可以收到钱的？我们又有几个项目是可以不失败的？
客户是上帝。可是我们真的是把客户作为上帝，还是把我们自己的技术欲望作为上帝了呢？
终于把这本书看完了，大牛们的项目也终于失败了。看到后期一直在想一个问题。程序员到底是建筑工人还是艺术家？
现在，国内受印度软件外包模式的影响，认为程序员就是建筑工人。一个完整的程序建立过程就是一栋建筑的构建过程。可是在实际过程呢？我们永远无法准确估计进度，就像我们永远不知道下一个巧克力是什么味道。
“好，没问题，月底肯定能完成！”
“哦！出了点小问题，再有一个礼拜吧？”
“程序已经发到测试部了！有没有问题问测试吧！”
“哦！这个我们没有考虑到等等吧，我们尽快！”
“什么？你什么时候说过这个问题啊？”
工程进度！？好像成了一个谜，而且是一个永远无法破解的谜！无法估计，无法考核。程序员总在认为自己的工作不是在累砖和泥！认为自己在从事一个艺术品，可是谁听说过艺术品还有规定工期和逻辑性的？
所以问题还是绕回到最初，我们到底是在干什么？我是为谁在做？
-------------------------------------------------------------------------------------------------------------------
外国大牛也不过如此
来自: 庄表伟
花了一周的时间，看完了《Dreaming in Code》（梦断代码），看得我心潮起伏。对里面那帮家伙的评价也起起落落。最终的结论是：外国大牛也不过如此。
别看他们名头那么响，做了那么多超有名的项目，实际的能力（软件开发能力与项目管理能力）看来相当有限。感想很多，想到一点说一点吧。
1、以前有一篇文章叫“谦卑的程序员”，有这么一段话：“优秀的程序员很清楚自己的能力是有限的，所以他对待编程任务的态度是完全谦卑的，特别是，他们会象逃避瘟疫那样逃避‘聪明的技巧’”。但是，那些所谓的大牛，却一点的不知道这一点。一开始他们就决定要做一个桌面软件，然后打算用python+wxWidgets来实现。到后来我才知道，这帮家伙居然一个都不懂python的桌面开发。那个他们伟大的梦想——要打通所有的数据间的隔阂——究竟意味着多少技术难度，他们心里也一点数都没有。总之，这些“大牛”，让人想到的是自我感觉良好的“半瓶醋”。他们的目标太伟大了，这是我在看到这本书的中段的时候的体会。技术要最新潮的，软件要革命性的，要平台化以支持插件的，用户体验要最好的，代码要开源的，唯独工期是不确定的。越是伟大的目标，越是需要强有力的风险控制能力。再引用一遍范总的格言：“欲望不要超过能力”。而他们，就根本没有意识到自己的能力严重不足。
2、一个team中，牛人太多了！如何才能良好的合作呢？他们永远在开会，却始终议而不决，大家都是管过“大团队”的。要他们几个人合作起来Coding，就太难了。
3、还有一个证明他们不是“大牛”的证据是，他们缺乏技术决断力，那几年里流行起来的很多技术，他们都有随波逐流的冲动。比如他们尝试过RDF 来描述数据；尝试过Python的ZOPE；憧憬过P2P（但是他们的团队里没有一个懂P2P的）；企图从wxWidgets转到Mozilla的 XUL。。。怎么说呢？这样的摇摆和见异思迁，简直是典型的初哥的作风。真正的大牛，对于技术的趋势，以及如何在项目中运用，心中都自有判断的。
4、据说Chandler 1.0也正式发布了，我去下载了一个，希望能够有惊喜发生~~还是奇慢无比，根本就不具备实用价值！
5、如果是我来做这个项目的话，首先就不会在这么多个方面同时冒险。其次，在项目开始之前会先安排一个技术可行性的研究阶段。最重要的一点，我会早点把不称职的“大牛”开走。
别看他们名头那么响，做了那么多超有名的项目，实际的能力（软件开发能力与项目管理能力）看来相当有限。感想很多，想到一点说一点吧。
1、以前有一篇文章叫“谦卑的程序员”，有这么一段话：“优秀的程序员很清楚自己的能力是有限的，所以他对待编程任务的态度是完全谦卑的，特别是，他们会象逃避瘟疫那样逃避‘聪明的技巧’”。但是，那些所谓的大牛，却一点的不知道这一点。一开始他们就决定要做一个桌面软件，然后打算用python+wxWidgets来实现。到后来我才知道，这帮家伙居然一个都不懂python的桌面开发。那个他们伟大的梦想——要打通所有的数据间的隔阂——究竟意味着多少技术难度，他们心里也一点数都没有。总之，这些“大牛”，让人想到的是自我感觉良好的“半瓶醋”。他们的目标太伟大了，这是我在看到这本书的中段的时候的体会。技术要最新潮的，软件要革命性的，要平台化以支持插件的，用户体验要最好的，代码要开源的，唯独工期是不确定的。越是伟大的目标，越是需要强有力的风险控制能力。再引用一遍范总的格言：“欲望不要超过能力”。而他们，就根本没有意识到自己的能力严重不足。
2、一个team中，牛人太多了！如何才能良好的合作呢？他们永远在开会，却始终议而不决，大家都是管过“大团队”的。要他们几个人合作起来Coding，就太难了。
3、还有一个证明他们不是“大牛”的证据是，他们缺乏技术决断力，那几年里流行起来的很多技术，他们都有随波逐流的冲动。比如他们尝试过RDF 来描述数据；尝试过Python的ZOPE；憧憬过P2P（但是他们的团队里没有一个懂P2P的）；企图从wxWidgets转到Mozilla的 XUL。。。怎么说呢？这样的摇摆和见异思迁，简直是典型的初哥的作风。真正的大牛，对于技术的趋势，以及如何在项目中运用，心中都自有判断的。
4、据说Chandler 1.0也正式发布了，我去下载了一个，希望能够有惊喜发生~~还是奇慢无比，根本就不具备实用价值！
5、如果是我来做这个项目的话，首先就不会在这么多个方面同时冒险。其次，在项目开始之前会先安排一个技术可行性的研究阶段。最重要的一点，我会早点把不称职的“大牛”开走。
作者：木木
