第9章 方法
经过两年多的工作，OSAF开始有了固定的工作流程，还有了一套可能让它朝 目标行进的可行的方法论。最早要做好现实的计划和进度安排，但是成功的流程难以捉摸， 没有任何一种方法论能够覆盖软件项目的广大领域，但是结构化编程、改进组织代码的方式仍然 是有利于工作进程。 在团队项目开发中，虽然由于个人或者团体的原因会使原定的计划产生偏差，但是还是避免 了重新定制计划所带来的缓慢、延误，所以制定一个合理的计划并努力遵循它还是必然的。
第10章 工程师和艺术家
“软件”与“工程”密不可分，对软件可靠性、质量控制、成本控制和进度安排等的 方面，软件由艺术上升到工程，诸多程序员却并不满意这样的跨越。 工程师就是要遭艺术与科学的深渊上搭起桥梁，对未来不可见的软件做出可靠性的 行为预测，这个角色也是十分具有重要性的。 编程的双重身份问题，几十年来一直困惑着广大的程序员们，是工程还是文学？ 我觉得这并不矛盾，作为一项艺术品，它必须拥有艺术的灵感与创新，但是又不能 绝对的盲目开发，要有像工程一样的大体规划。
第11章 通往狗食版之路
OSAF“狗食版日历”的开发历程。首先设计师考虑到用户管理的流程，所作出的 项目改进计划是在OSAF设计组中经过争论和不断修改酝酿成熟的。 “测试驱动方法”的使用，使程序员们更好的测试代码，确保代码在每个阶段 都能够正确运行。其中Chandle的独特设计带来了诸多问题，比如如何处理重复 事件， 经过三年之后，Chandle终于开始成了某种虽未完成但还算可用的日历程序， 但又是很长的一段时间，最终交付了用户所能使用的软件，并将这个项目名命名为Scooby。 发布之前又要修复缺陷，获得实践反馈，然后试用，对待停机问题，最终终于发布。 任何一个创新的历程都是艰辛的，都需要付出更多的汗水和心血。