解决软件系统的问题是很复杂的，尤其是涉及到多个交互作用的软件产品，那就更加复杂。当工具和特许部件本身就是软件产品时，你怎么知道何时可以信赖这些工具和部件呢？
调试一个系统就是一个确认有关该系统的许多假设的过程，而这些假设在发现其不正确之前，你都认为是正确的。那你如何把你的所有假设变为明确无误、可核实的事实呢？编制一种包罗万象的、无任何歧义的规范是富有挑战性的，因为自然语言是天生不精确的，发生模棱两可和依赖含蓄假设的可能性大量存在。请想一想你应用于每一种情况的、能被人们准确理解的而又无任何歧义的法律的成功率吧。当技术规范中的假设不准确时，所设计的系统就没有像法院庭审那种奢侈来消除歧义的细节。系统即使性能不理想也将按照所设计和制造的那样运行。
许多专业学科都预计到错误是难以避免的，并对系统中的错误做出说明。软件供应商通常提供维护的插入补码，用以更新功能和修补软件错误。运输工程师利用警察部门的事故报告中的发展趋势来重新评估和修改道路的布局和交通控制。插入补码固件是一种适应事先未曾考虑到的
而又已进入生产系统的硬件特性的一种机制。飞机上装有数据记录器，供坠机后分析，利用这种分析结果人们可以改变新飞机和现有飞机的设计过程、生产过程以及维护过程。
那么软件供应商怎么可能继续声称他们提供的是零缺陷软件呢？这种说法通常只是指该软件符合某种技术规范和某种严格控制的环境而已。在这种情况下，这种技术规范中的要求不全和错误不是软件错误。然而，制定一个包罗万象、完全无错的规范通常要比制造一个实际系统更为复杂。在笔者参与许多项航天飞船和飞机工程期间曾流传这样一个笑话：设计工作要到其文件的重量大大超过最终系统和要建造的设备的重置时才接近完成。实际上，技术规范常常依赖于对系统行为特征化的简化描述，而人们希望这种描述等同于所需要的结果。这样做的风险就在于，任何简化或抽象化都可能省略或没有充分描述重要的细节。
实际上，一个嵌入式系统要正常运行，软件承担了很大一部分责任。在时间和资源受限制的情况下，对软件进行全面测试是不切实际的，因为可能的输入和执行路径太多，根本测试不过来或者并行执行和界面问题太复杂，测试无法面面俱到。即使你能够在有限的时间里全面测试软件，你的项目难道能因为反复地测试软件，甚至为每一种不太可能的应用场合进行测试，直到软件完全无差错，而丧失上市的机遇吗？即使到了软件完全无差错的时候，客户也可能会按你未预想到的和你未试验的方式使用你的产品。
总是软件故障吗？
当问题不一定出自软件错误时会怎样呢?系统行为取决于硬件与软件的紧密配合，特别在嵌入式系统中。同样也存在着与第三方软件供应商所提供的软件的紧密配合问题，如生成代码的编译程序和汇编程序，或与代码同时执行的操作系统、中间件、特许算法和驱动程序。如果改变其中某个部件而没有考虑到其他部件，那么你的系统各个部件之间的相互作用就会中断。但是，当一个生产系统不正常工作时，一般是通过修改软件来解决问题。这是否就意味着多数问题都是软件故障引起的呢？问题的答案可能是“既是又不是”，视你如何看待系统而定。
软件错误分4类，即语法错误、印刷错误、逻辑错误和管理性错误。语法错误实质上是语法上的错误，编译程序和代码检验程序可以标出这类错误。印刷错误在语法上是正确的，但是你可能错误地确定或拼写某个词，因而引用错误的功能或资源。命名规定、规则和资源范围管理能有助于发现和最大程度减少这类错误。逻辑错误包括没有完成你想要的功能的代码，并说明对设计规范作了错误的解释或对某个功能调用或外设该如何运行作了错误的假设。管理性错误包括如下情况：代码是正确的，但是如果你不正确地使用工具，包括某个代码模块的错误版本或未能对两次复位之间的测试环境正确进行初始化，那么结果是操作不正确。
软件工程师一般会争辩说：只要内部代码错误地实施规范，你就应把错误算作软件错误；如果软件符合规范，你就应当宣布软件是正确的。软件总是按照设计运行；要么规范是错误的，要么系统中的其他部分运行不正常。然而，即使规范、硬件或其他软件模块或许是产生错误行为的根源，问题仍然需要加以解决。最便捷的方法往往是通过修改软件来解决问题或绕开问题。从系统的角度看，如果软件能够检测出问题的征兆并做出反应以避免出现不希望的行为，那么这就是软件问题。
信赖你的工具
知识媒体研究所(Knowledge Media Institute)的首席科学家 Marc Eisenstadt 博士在研究了世界各地59个人的轶事性质的调试经验后得出如下结论：存储器改写和供应商提供的硬件或软件有问题是故障的两大根源，占所报道事故的40%以上（参考文献 1）。很可能发生的情况是，你信赖你系统中大量由