今天我看到了本书的第九章，本章主要讲了关于软件开发的方法论。同时作者为我们介绍了软件缺陷编年史上数量不多但是足以警示世人的惊人灾难。
1962年6月，水手一号探测飞船在发射5分钟后偏离轨道，为避免坠入居民区，飞行控制人员只好将其引爆。问题在哪？导航控制程序中少了一个连字符。1996年6月欧洲航天局投入5亿美元建造的阿丽亚娜5号无人运载火箭发射后40分钟爆炸，原因是在控制其导航系统的程序中有一个缺陷。（代码要将64位变量转换为16位变量，但是数字太大，出现缓存溢出，系统停滞了。）从1985年到1987年，由于软件缺陷，一台放射治疗仪向6名患者放射了过量的X射线。在1991年的海湾战争中，在飞毛腿导弹袭来时，由于爱国者导弹的一个电池未能成功点火，敌方导弹击中美国营地，导致28人死亡。调查发现，由于软件中存在一个累积计算错误，经过数百小时的使用之后，爱国者导弹的计数会变得非常大，从而无法点火。
上述事例以及类似故事数量太少，不足以引起媒体的愤怒和政治上的骚动，但它们却警示着我们对于程序员工作质量的依赖。
由此更引发了我们对于软件开发过程中的项目组织方式的思考。几十年来，典型的项目组织方式遵循“瀑布模型”——将项目切分成为依序进行的多个独立阶段，比如需求定义、设计、实现、集成、测试、和发布。每个阶段需在下个阶段开始前完成。这套做法在纸上看起来合乎逻辑。但是实践起来总是不可避免的导致延误、混乱、和灾难。每个阶段都耗时无算，但每一个工作正常的。程序员们要么坐等需求，要么在拿到需求之前就开始做设计。“大设计优先”引发大延误，“大爆炸式集成”——单独编写代码的各个主要部分，在项目将近结束的时候拼接在一起——导致崩溃。到产品终于完成的那一天，已经过了很久，该程序要解决的问题已经无关紧要了，新的问题又在呼吁解决方案。
之后又出现了一种“螺旋模型”的替代方案。将开发切割成为六个月到两年的“迭代周期”。可更快生产出可工作代码的“小瀑布”。从部分完成的产品使用中得到反馈、指导下一代迭代。这个模型在大规模政府承包软件开发中逐渐成为标准，但在商业软件的飞速发展中还是太慢。
在20世纪90年代又出现了一种“极限编程”的开发方式。这中方式强调个体和交互胜于过程和工具，可工作的软件胜于面面俱到的软件，客户协作胜于合同谈判，响应需求胜于遵循计划。尽管后者均有其价值，但是我们还是更关注前者。这种开发方式虽然免去了重量式开发的条条框框，但也给一些程序员找到了一些借口，他们只遵循让他们舒服的规矩。所以在开发过程中出现了很多混乱状态。
关于开发方式的探索仍在继续。