这本书讲了这样的故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。
1）驱动
到底是什么驱动程序员和管理人员，测试人员长年累月投入到一个软件项目中去？
有理论认为，传统的软件公司用工资，职位，绩效考核等让一群经过面试和培训的人在严格定义的流程下一起工作（大教堂/Cathedral模式）。其实，用开源，社区，共享的模式会更好（集市/Bazaar模式）也许更好。正如在第26页所说的 [所有页码都是指英文版]
在Chandler 项目中，Andy Hertzfeld 就是这样一个义务作贡献的大牛。但是他也遇到了同样的"志愿者问题" –
2）责任 和驱动紧密相关的，是责任 – Accountability.
在 Hard Drive 这本书中，讲了这样的故事 – 由于Windows 一再拖延，BillG 最后跟 SteveB 说 – 如果今年下雪之前Windows 还没出来，你就别在这儿干了。 书中没有详细讲 SteveB 回头来又和他的团队讲了什么，但是第二天一个员工背着睡袋进驻了办公室。
很多年以后，Windows Vista 也经历了很长的拖延，在又一次宣布拖延之后，人们发现 Windows 团队中一个赫赫有名的 VP 已经卷起铺盖走了。
我们回过头来看，在Chandler 项目长达7年的拖延中，有没有发生过各位项目管理者引咎辞职的事？ 好像没有。 [有不少人离开，但是没有人直接为项目延期负责] 既然我上一次拖延没有什么惩罚，那我为什么一定要拼了老命要避免下一次拖延呢？
在传统意义上的软件公司，如果项目延期，那项目原计划的收入就拿不到，拖延的时间再长一些，员工就得走人，否则整个公司都被拖垮了。在“集市”，社区，共享的模式下，大家都是义务，大家都在玩票，大家都做贡献，但是对最终项目不直接负责任，那到底谁负直接责任呢？
在《移山之道》 中，有下面的例子：
阿超：我今天在“顶球”网吧看到大牛他爹在下棋，围观者支招的不少，有的说上马，有的说拱卒，有的说出车。大牛他爹一会儿招法就乱了，眼看局势不灵了，围观者一哄而散，老崔后来也没法，只好认输了。
一个围棋国手在一次重要的对局后，听到旁观者对棋局的进程有很多不同的看法，他也没有过多争辩，只是说：“无责任的旁观者和有重大责任的当局者的看法自然是不一样的”。
无责任的旁观者在支招后，如果不灵，他可以面不改色地继续支招，甚至可以给另一位对局者支招，不管最后谁输谁赢，旁观者随时都能安心地离开，回家吃饭。有重大责任的当局者在走了损招或败招之后，他很可能就要认输下台，丢掉比赛的奖金和头衔。
一个软件团队可以制定出动人的远景/Vision， 但是如果大家没有搞清楚驱动项目的各种因素和每个角色应付的责任，那Vision只是一句话而已。