看了这几本有关软件的书，发现作者们都是喜欢举例，用事实说话。但又与前两本不同，它讲述的是作者以及像作者这样的开发者们自己的故事，是作者作为一个软件行业的工作者所经历所感慨的种种。第一章却不叫第一章反叫第零章，作者的解释令人叹服，在计算机的世界里，数字是从0而不是1开始计数的。人类文明运行于软件之上，但在软件业的日渐成熟下，人类的日常生活早就离不开软件。对软件的依赖指数级的增长，但做软件的技能和应用技能的愿望却增长缓慢。
chandler团队的开发人员们计划修改一个拖慢他们开发进程的bug，需要4小时，但是实际上8个小时也没做出来，甚至给他8天也解决不了。而这个bug最终被解决是在几个月后。正像这位开发人员所说：有时候，你一觉醒来，脑中灵光闪现，于是手到擒来--大抵如此。有软件的时间这个总让人头疼的问题，布鲁克斯法则就产生了：往以延误的项目中补充人力，只会使其继续延误。这话王老师也曾在课堂上对我们讲过。已经延误的项目，其中的问题想必已经一对，这时团队中再添加新的成员，新的成员还要花时间去熟悉项目，与老成员们还要相互磨合，不是更加拖慢团队进程？
chandler起初本身是一个个人信息管理器，它的功能包含邮件，地址簿等等。像这种功能，微软的outlook已经做到了。所以，为了使它更与众不同，不断地引入了新的需求，使得后来越做越乱，进入了深深地无底洞中。项目在一开始时就没有明确的目标，在研发的途中不断添入新的需求，收效甚微。长达半年的时间，chandler团队才开发出一个pre-alpha版本，大家都在被各种各样的问题困扰着，停滞不前。2003年4月21日下午3:07，公众版chandler0.1公布于世。24小时内就被下载15000万次。这当然是不小的成功，但依旧存在问题，“底层数据库仍待大改”。安迪·维达的到来，快刀斩乱麻结束了关于ZODB长达几个月的讨论，将chandler团队起码拉回到了有进展的世界。