第4章讲述了当时技术工业处于了最低点时期，大量程序员失业，而同时在这个特殊时期OSAF获益匪浅，相继有志愿者和员工加入OSAF。软件常常涉及前台和后台，Chandler的后台工作陷入了艰难技术决定，他们需要一种“对象持久化”的机制，最简单的手段是采用另一种数据库技术，即对象数据库。各种部分的需求也越来越多，正经历一个危险时期。他们经过讨论开始了尝试，但是也遇到了很多难题。最后OSAF发布了Chandler第一个里程碑版本（其实是内部版本），虽功能很少，但是给团队成员带来了安慰和鼓励。
第5章管理软件必须要做交易，在软件世界里，多数选择都归为令人神伤的三向交易，通常都为坏消息。在对Chandler后端的争论开始后，卡普尔就认为需要聘请一位项目经理，来定制进度、做决定。为OSAF寻找项目经理的工作缓慢，软件项目管理中存在一种充满讽刺意味的天性，多数项目经理很清楚项目中的困难，他们会提前做些什么。在软件管理中，协作是工作的核心，OSAF在4月份发布了Chandler0.1版，接下来就是完整的设计方案。
第6章开篇通过作者想要备份方案，拖动了文件夹，但是文件夹却没有了，最后通过撤销文件夹恢复。卡普尔对软件的设计总是抱有热情，也一直致力于将软件设计确立为独立的专业领域。他的好多说法在今天看来都足以自证。他们关注的主题转向了文档，小组的讨论开始叫做文档架构会议，经过一个月后，他们遇到的问题解决了。卡普尔从0.2版吸取教训—该死的布鲁克斯法则。
第7章Chandler0.3版发布，意味着现在设计组渴求一张更彻底、更接近最终需要的Chandler外观和行为路线图，他们需要细节、需要蓝图、需要规格说明。规格说明是程序员的圣经，共享信息是Chandler最重要的特性之一。Chandler缓慢进展被怀疑，感觉永远也做不出来，但是一直坚持，坚信总会有回报。
