在第八章白板上的即时贴中，一开始提到了“吃你自己的狗食”，意思是开发者必须使用自己正在做的产品。获得更好进展的关键是将软件改进到他们自己可以使用的程度。在IETF，杜索特参与制定新标准WebDav,对于许多程序员来说，标准领域是一片令人畏惧的沼泽地。但是杜索特说，当你把系统的一块新部件放进去，总要先看看之后5年或十年间自己会不会后悔，你是否能扩展它，代替它。WebDav的工作机制是扩展http，接着谈到了p2p，重要的是受人以能，而非架构本身。之后提到了电子表格，虽然清晰但是巨大，杜索特建议用贴纸，每张纸表示大致同等的工作量，每张即时贴代表带个开发者一个月或两个月的工作时间，从而有了白板上的即时贴这个名词。
在第九章方法中，开始的时候提到了质量三角，即时间，金钱和特性，chandler软件下载数量颇低，虽然有很多流程，但是也无济于事。于是谈到了改进组织代码的方式，最终是与改进组织人员及其工作方式之间的步态竞争。其中一派说好计划太有价值，但是太难制定，你得更努力的做计划，花更长时间，更细节化，然后再做一次计划！直至无所计划为止--然后再做一点计划。随后项目管理大师提出了必须做出更多计划的主张：除非开发者为个人工作制定计划并遵循之，否则工作将不可预料。汉弗在IBM执行强制进度几率的成功基于两条原则：计划是强制性的，计划必须符合现实情况。后来提到了方法中的价值观：个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，相应变化高于遵循计划。
在第十章工程师和艺术家中，谈到了“软件”与“工程”密不可分，对软件可靠性、质量控制、成本控制和进度安排等的 方面，软件由艺术上升到工程，诸多程序员却并不满意这样的跨越。 工程师就是要遭艺术与科学的深渊上搭起桥梁，对未来不可见的软件做出可靠性的 行为预测，这个角色也是十分具有重要性的。 编程的双重身份问题，几十年来一直困惑着广大的程序员们，是工程还是文学？ 我觉得这并不矛盾，作为一项艺术品，它必须拥有艺术的灵感与创新，但是又不能绝对的盲目开发，要有像工程一样的大体规划。
在第十一章通过狗食版之路中，了解到了OSAF“狗食版日历”的开发历程。首先设计师考虑到用户管理的流程，所作出的 项目改进计划是在OSAF设计组中经过争论和不断修改酝酿成熟的 “测试驱动方法”的使用，使程序员们更好的测试代码，确保代码在每个阶段 都能够正确运行。其中Chandle的独特设计带来了诸多问题，比如如何处理重复 事件， 经过三年之后，Chandle终于开始成了某种虽未完成但还算可用的日历程序， 但又是很长的一段时间，最终交付了用户所能使用的软件，并将这个项目名命名为Scooby。 发布之前又要修复缺陷，获得实践反馈，然后试用，对待停机问题，最终终于发布。 任何一个创新的历程都是艰辛的，都需要付出更多的汗水和心血。
个人感受
以前，我对于软件工程的一些方法的由来并不是很了解，对其发展也是，没有想到它的发展历程是如此多的曲折和困难，通过读这最后四章的内容，让我明白了其实每一个使用的方法和理论的产生都是需要实践检验的，俗话说的好，实践是检验真理的唯一标准，每一个产品和标准都是来之不易的。
现在，我更加对这些前辈充满了敬佩之情，他们的那种时代精神是我们不可或缺的，我们真的应该学习这种精神，无论是当下还是在未来，把这种精神化作一种动力，努力探索和完善软件工程，在前人的基础上正确作的更好更远。
通过阅读这最后四章的内容，我觉得要想解决我们当下的难题，我们应该学习书中程序员们勇于探索的精神，我觉得其实虽然我们现在已经站在前人的基础上开发项目相对容易一些，但是我们仍然缺乏那种勇于探索的精神，这种精神是哪个时代都不可以缺乏的！