2.4 软件开发神话
软件开发神话，即关于软件及其开发过程的一些被人盲目相信的说法，这可以追溯到计算技术发展的初期。神话具有一些特点，让人觉得不可捉摸。例如，神话看起来是事实的合理描述（有时的确包含真实的成分），它们符合直觉，并且经常被那些知根知底的有经验的从业人员拿来宣传。
今天，大多数有见地的软件工程师已经意识到软件神话的本质——它实际上误导了管理者和从业人员对软件开发的态度，从而引发了严重的问题。然而，由于习惯和态度的根深蒂固，软件神话遗风犹在。
管理神话。像所有领域的经理一样，承担软件职责的项目经理肩负着维持预算、保证进度和提高质量的压力。就像溺水人抓住稻草一样，软件经理经常依赖软件神话中的信条，只要它能够减轻以上的压力（即使是暂时性的）。
神话：我们已经有了一本写满软件开发标准和规程的宝典，难道不能提供我们所需要了解的所有信息吗？
事实：这本宝典也许的确已经存在，但它是否在实际中采用了？从业人员是否知道这本书的存在呢？它是否反映了软件工程的现状？是否全面？是否可以适应不同的应用环境？是否在缩短交付时间的同时还关注产品质量的保证？在很多情况下，问题的答案是否定的。
神话：如果我们未能按时完成计划，我们可以通过增加程序员人数而赶上进度（即所谓的“蒙古游牧”概念）。
事实：软件开发并不是像机器制造那样的机械过程。Brooks曾说过[Bro95]：“在软件工程中，为赶进度而增加人手只能使进度更加延误。”初看，这种说法似乎与直觉不符。然而，当新人加入到一个软件项目后，原有的开发人员必须要牺牲本来的开发时间对后来者进行培训，因此减少了本应用于高效开发的时间。只有在有计划且有序进行的情况下，增加人员对项目进度才有意义。
神话：如果决定将软件外包给第三方公司，就可以放手不管，完全交给第三方公司开发。
事实：如果开发团队不了解如何在内部管理和控制软件项目，那么将无一例外地在外包项目中遇到困难。
客户神话。软件产品的客户可能是隔壁的某个人、楼下的一个技术团队、市场／销售部门或者签订软件合同的某个外部公司。多数情况下，客户之所以相信所谓的软件神话，是因为项目经理和从业人员没有及时纠正他们的错误信息。软件神话导致客户错误的期望，最终导致对开发者的不满。
神话：有了对项目目标的大概了解，便足以开始编写程序，可以在之后的项目开发过程中逐步充实细节。
事实：虽然通常很难得到综合全面且稳定不变的需求描述，但是对项目目标模糊不清的描述将为项目实施带来灾难。要得到清晰的需求描述（经常是逐步变得清晰的），只能通过客户和开发人员之间的持续有效的沟通。
神话：虽然软件需求不断变更，但是因为软件是弹性的，因此可以很容易地适应变更。
事实：软件需求的确在随时变更，但随变更引入的时机不同，变更所造成的影响也不同。如果需求变更提出得较早（比如在设计或者代码开发之前），则对费用的影响较小；但是，随着时间的推移，变更的代价也迅速增加——因为资源已经被分配，设计框架已经建立，而变更可能会引起的剧变，需要添加额外的资源或者修改主要设计。
从业者神话。在60多年的编程文化的滋养下，软件开发人员依然深信着各种神话。在软件业发展早期，编程被视为一种艺术。旧有的方式和态度根深蒂固。
神话：当我们完成程序并将其交付使用之后，我们的任务就完成了。
事实：曾经有人说过，对于编程来说，开始得越早，耗费的时间就越长。业界的一些数据显示，60%～80%的工作耗费在软件首次交付顾客使用之后。
神话：直到程序开始运行，才能评估其质量。
事实：最有效的软件质量保证机制之一——技术评审，可以从项目启动就开始实行。软件评审（第20章）作为“质量过滤器”，已经证明其可以比软件测试更为有效地发现多种类型的软件缺陷。
神话：对于一个成功的软件项目，可执行程序是唯一可交付的工作成果。
事实：软件配置包括很多内容，可执行程序只是其中之一。各种工作产品（如模型、文档、计划）是成功实施软件工程的基础，更重要的是，为软件技术支持提供了指导。
神话：软件工程将导致我们产生大量无用文档，并因此降低工作效率。
事实：软件工程并非以创建文档为目的，而是为了保证软件产品的开发质量。好的质量可以减少返工，从而加快交付时间。
目前，大多数软件专业人员已经认识到软件神话的谬误。对于软件开发真实情况的正确理解是系统阐述如何使用软件工程方法解决实际问题的第一步。