以下文字来自《软件工程的事实与谬误》（http://book.douban.com/subject/1723351/）。
关于构建软件，我们理应知道许多东西，但是实际上却因为这样或那样的原因不知道，甚至我们想当然的一些看法实际上是显而易见的错误。本书抽取软件行业中经典的55个基本事实和10个谬误进行分析，对于每个观点，作者都提供观点的来源和证据，以及相关的参考文献。除此之外，还介绍业界对这个观点的其他不同的认识和理解。可能并非所有的读者都喜欢书中的这55个事实，其中有些事实与某些所谓的现代方法截然相反，但了解这些事实一定大有裨益。
1管理
1.1人员
事实1：在软件开发中，最重要的因素不是程序员采用的工具和技术，而是程序员自身的质量
事实2：对“个体差异”的研究表明，最好的程序员要比最差的程序员强28倍之多。即使他们的报酬不同，优秀程序员也是软件业中最廉价的劳动力。
事实3：给延期的项目增加人手会使项目进一步延期。
事实4：工作环境对工作效率和产品质量具有深刻影响。
1.2工具和技术
事实5：夸大宣传是软件的瘟疫。多数软件工具对于效率和质量的提高幅度仅为5%~35%。但是总有人反复说提高幅度是“数量级”的
事实6：在学习新工具或者新技术的初期，程序员的工作效率和产品质量都会下降。只有克服了学习曲线以后，才可能得到实质性的效益。只有满足下面两个条件，采用新工具或新技术才有意义：（a）新东西确实有用；（b）要想获得真正的收益，必须耐心等待。
事实7：软件开发者对于工具说的多，评估的少，买的多，用的少。
1.3估算
事实8：项目失控的两个最主要的原因之一是糟糕的估算（另一个原因见事实23）
事实9：许多估算是在软件生命周期开始时完成的。后来，我们才认识到在需求定义之前，即理解问题之前进行项目估算是不正确的；也就是说，估算时机是错误的。
事实10：许多软件项目都是由高层管理人员或者营销人员来估算，而不是由真正构建软件的人或者他们的主管来进行估算。因此，估算软件的人员是错误的。
事实11：软件估算很少根据项目进度进行调整。因此，这些估算通常是错误的人在错误的时间得出的错误的结果。
事实12：因为估算的数据如此糟糕，所以在软件项目不能达到估算目标时，不应该再考虑估算。但是无论如何，每个人都在考虑它。
事实13：在管理者和程序员之间存在隔阂。对于一个未满足估算目标的项目的调查表明：从管理者看来这是一个失败的项目，而在技术人员看来确实最成功的项目。
事实14：对于可行性调研的回答几乎总是“可行”。
1.4复用
事实15：小规模的复用（子程序库）开始于50多年以前，这个问题已经得到很好的解决。
事实16：虽然每个人都认为大规模复用（组件）非常重要、非常急需，但是这个问题至今还没有基本解决。
事实17：大规模复用最好适用于相关的系统，也就是依赖于具体应用领域，这样就限制了它的应用范围。
事实18：有关复用问题，有两个“三倍原则”：（a）构建可复用的组件比使用组件难三倍；（b）在将组件收录到复用库并成为通用组件之前，应该在三个不同的应用中尝试应用该组件。
事实19：修改复用的代码特别容易引起错误。如果一个组件中超过20%~25%的代码需要修改，那么重新实现的效率会更高。
由此引出的另外一个事实是：修改经过打包的商业性软件系统通常是错误的。
事实20：设计模式复用是解决代码复用中固有问题的一种方法。
1.5复杂性
事实21：问题的复杂性每增加25%，解决方案的复杂性就增加100%。这不是一个可改变的条件（即使人们都努力降低复杂性），而是客观存在的。
事实22：80%的软件工作是智力活动。相当大的比例是创造性地活动。很少是文书性的工作。
2生命周期
2.1需求
事实23：导致项目失控的两个最常见原因之一是不稳定的需求（另一个见事实8所说的项目估算失误）。
事实24：在产品完成时修订需求错误的代价最大，在开发早期修订需求错误的代价最小。
事实25：遗漏需求是最难修订的需求错误。
该事实的一个必然结论是： 最持久的软件错误是遗漏逻辑错误，它可以逃过软件测试过程，进入发布的产品中。遗漏需求会导致遗漏逻辑。
2.2设计
事实26：从需求转入设计时，因为制定方案过程的复杂性，会激增出大量的衍生需求（针对一种特定设计方案的需求）。设计需求是原始需求的50倍之多。
事实27：对于一个软件问题，通常不存在唯一的最佳设计方案。
事实28：设计是一个复杂的、迭代的过程。最初的设计方案可能是错误的，当然也不是最优的。
事实29：从设计到编码阶段时，设计者按照自己掌握的水平，已经将问题分解为“原语”。如果编程者和设计者不是同一个人，二者的“原语”不吻合，就会出问题。
事实30：COBOL是一种非常糟糕的语言，但是其他的（用于商业数据处理的）语言也同样糟糕。
事实31：错误消除是软件生命周期中最耗时的阶段。
事实32：普通程序员认为已经彻底测试过的软件其实只执行了55%~60%的逻辑路径。采用覆盖分析器等自动工具，可以将上述比例提高到85%~90%。几乎不可能测试软件中100%的逻辑路径。
事实33：即使测试覆盖有可能达到100%，这种测试也不够。大约35%的错误是源于逻辑路径的缺失，还有40%的错误源于执行特定的路径组合。不可能实现100%的覆盖。
事实34：没有工具就无法做好错误消除工作。人们常用调试器，很少使用覆盖分析器等其他工具。
事实35：自动测试很少，也就是说有些测试可以也应该自动化，但是有许多测试任务不能自动完成。
事实36：程序员在程序中嵌入测试代码、目标代码中的编译参数等方法，都是测试工具的重要补充。
事实37：在运行第一个测试用例之前进行严格审查可以消除软件产品中多大90%的错误。
事实38：虽然严格审查有很多优点，但是不能也不应该代替测试。
事实39：通常认为，事后评审对于了解客户的满意度和改进过程都很重要。但是很多软件公司不开展事后评审。
事实40：同行评审涉及技术和社会两方面问题，忽视任何一方面都回产生严重的灾难。
2.7维护
事实41：维护开支通常占软件成本的40%~80%（平均为60%）。因此，维护可能是软件生命周期中最重要的阶段。
由此引出的一个必然结论：古老的硬币会被抛弃，古老的软件每天都在使用。
事实42：增强功能大约占软件维护成本的60%，错误更正仅占17%。因此，软件维护的主体是在旧软件中加入新功能，而不是更正错误。
事实43：维护是解决方案，而不是解决问题。
事实44：比较软件开发和软件维护中的工作，除了维护中“理解现有的产品”这项工作之外，其他工作都一样。这项工作占据了大约30%的维护时间，是主要的维护活动。因此可以说维护比开发更难。
事实45：更好的软件工程开发导致更多而不是更少的维护。
3质量
3.1质量
事实46：质量是一组属性的集合。
事实47：软件质量不是用户满意、满足需求、满足成本和时间表目标，或者可靠性。
3.2可靠性
事实48：绝大多数程序员都会犯某些错误。
事实49：错误通常聚集在一起。
事实50：没有唯一最好的消除软件错误的方法。
事实51：总会有残存的错误。我们的目标应该是消除严重错误，或者使之最少。
3.3效率
事实52：效率主要来自于优秀的设计，而不是优秀的编码。
事实53：高级语言（High-order language,HOL）代码配合适当的编译器优化，大约可以达到汇编语言90%的效率。对于一些复杂的现代体系结构，效率更高。
事实54：在空间和时间之间存在折中。通常，改进一方面会降低另一方面。
4研究
事实55：许多软件研究者不是做调查，而是鼓吹。因此，（a）有些概念比鼓吹的糟糕、更少；（b）缺少有助于确定这些概念真是价值的评估×××。
5+5谬误
5管理
谬误1：你不能管理自己无法度量的东西。
谬误2：可以管理软件产品的质量。
5.1人员
谬误3：可以，也应该“忘我”地编程。
5.2工具和技术
谬误4：工具和技术是通用的。
谬误5：软件需要更多的方法论。
5.3估计
谬误6：要估算成本和时间表，应首先估算代码行数。
6生命周期
6.1测试
谬误7：随机测试输入是优化测试的好方法。
谬误8：“假如有了足够多的关注，所有的bug都显而易见。”
6.2评审
6.3维护
谬误9：估计将来的维护成本和做出产品更新的决策需要参考过去的成本数据。
谬误10：教别人编程的方法是教别人写程序。
7教育
