我们已经看到双方的不同论据，现在我们必须决定如何权衡它们，以及如何避免把一些错误的行为合理化。首先，机器在迄今为止进行的例行试验中都运转良好。在Therac-25的案例中表明，一个复杂的系统可以正确运行过几百次，但是在异常情况下会出故障并导致致命的后果。你的客户可能不知道这一点。但是，你作为一个计算机专业人士，对于有关计算机程序的复杂性和潜在错误应该拥有更多的了解，特别是在与现实世界的事件进行交互的程序，例如操作员输入和控制机器的程序。我们假设在制定本机的原始测试计划的时候经过了深思熟虑。你应该延迟交付并完成所有测试。（参见SE准则1.03和3.10和ACM准则1.2。）
有些患者将会受益于按时交付。那么他们的利益是否应该与因为故障可能会遭到伤害的患者的利益拥有相同的权重？不一定。该机器代表的是医疗手段的改善，但并没有道德义务使它一定在某一特定日期给公众使用。你并不要对依靠现有的治疗手段的病人负责。你对将会使用该机器的人有义务，确保该机器的安全性达到了良好的专业实践可以到达的水平，其中就包括进行适当的测试。你在道德上没有义务治愈所有癌症患者。但是你在道德上有义务使用你的专业判断，使那些对这些一无所知的患者不会遭受额外的伤害[10]。
那么你对公司的责任呢？即使我们经过权衡认为，交付延迟带来的短期效应，会比由于故障造成的损失风险的权重更高，但是道德上的论据支持的是对机器进行充分测试的一方。是的，你有责任帮助你的公司走向成功，但是这并不是绝对的义务。（回忆第1.4.3节中讲过的关于目标和约束的内容。）如果我们用（从竞争对手或者客户）盗窃来讲解这个问题，或许区别会显得更明显。你对公司在财务上成功的职责，相对于道德约束来讲，是次要责任。在这个案例中，避免伤害到患者的不合理风险就是一种伦理约束（SE准则1.02）。
把一个产品推向市场
大多数产品都不是安全攸关的，它们的缺陷可能不会威胁到人们的生命。考虑如下的场景：
你是一个非常小的初创公司工作的程序员。公司拥有一个较为普通的产品线，并正在开发一个真正创新的产品。每个人都在每周工作60小时，而距离目标的发布日期还有9个月。编程和测试的大部分工作已经完成。你们即将开始进行beta测试。（参见第8.3.1节中关于beta测试的说明。）公司老板（他自己不是程序员）了解到有一个一年一度的行业展会，将会是推出新产品的理想场所。距离该展会只有两个月了。老板与项目经理进行了会谈。他们决定跳过beta测试，并开始着手准备提前发布的计划。
你是否应该提出异议？学生在讨论这个案例时，普遍认同这是一个糟糕的决定，该公司应该先做完beta测试。不过，他们的问题是，一个程序员是否有权表示抗议呢？你难道不是应该听从项目经理和你的直接上司所指派的任何事情？那么你是否应该什么都不说，应该说出来，还是干脆辞职？
考虑这个可能的结果：你要求与老板会面。你解释说该产品还没有准备好，beta测试是开发中一个非常重要的阶段，公司不应该跳过它。如果老板同意你说的话，会放弃提前发布的想法。按照原来计划发布的新产品是成功的。你最终成为一个冉冉升起的公司中的质量控制总监。
这不是一个童话。这是一个实际的案例，而且我刚才所描述的结果也是实际发生过的事情。这个案例提供了一个非常重要的观点：有时候人们会听你的话，当然，前提是你是令人尊重、思路周全和准备充分的。在另外一个真实的案例中，一个不属于软件部门的公司经理，要求程序员做一些事情，而程序员知道这不是一个好主意。虽然她担心她会因为拒绝经理的要求，可能会失去工作，她还是拒绝了，并提供了一个简短的解释。该经理接受了她的解释，而这个事件就这样结束了。人们经常会要求他们不一定指望会得到的事情。重要的是要记住，别人可能会尊重你的意见。你可能是认识到问题或理解某个特殊情况的唯一一个人。你对贵公司的责任包括运用你的知识和技能，以帮助避免错误的决定。在初创公司的案例中，站出来可能对本产品的成功和公司带来显著的影响。很多人是合理的，并且会认真考虑一个很好的解释或论点。许多人是这样，但不是所有人。一个小型电子公司的CEO提出，在三个月内要生产一个产品的新版本。工程总监（一个优秀的、经验丰富的软件工程师）撰写了所有必要步骤的详细时间表，并告诉CEO说，该项目需要花费一年多的时间。需要注意的是软件工程师并没有简单地告诉CEO，他认为三个月的计划是不合理的。他对它的说法提供了文字佐证。（这里适用SE准则2.06和3.09。）CEO把他换成了一个拥有“我能行”的态度的其他人。虽然似乎对这个工程师来说，他的结局是前两个案例的对立面，但这个案例也说明了对专业负责就是对自己负责。软件工程师不想要在极不合理的进度下的工作压力，也不希望承担必然失败的责任。在这种情况下，离开公司也不是一件坏事。