牢记业务上下文的技术决策建议，业务上下文是唯一的衡量软件质量的关键指标。
如果有事情不对劲，软件工程师会感到不安。学生或初级工程师由于不熟悉编程概念而感到不安。渐渐地，我们对更高层次的抽象感到不安：我们不再会像当初因缺乏理解而烦恼，而是知道系统确实属于有害反模式时，会更加不安。
不安情绪是我们即将面临问题的可靠指标。
普通或优秀的工程师都会感到这种不安，优秀的工程师会倾听自己的直觉，但会用自己的意识来思考是否应该执行某些操作。优秀的工程师会在不安和行动之间建立空间。优秀的工程师可以容忍缺陷。
在做出所有工程决策时，应了解其周围的业务环境。为什么要编写这段代码？这必须为您做出的决定提供依据。
假设您正在开发一个对某些数据进行操作的系统。您是否应该将某些数据保留在数据库，有序日志或属性文件中？是否需要永久保留它，还是可以在开始时重新计算？甚至接受重启后数据将丢失的信息？在真空环境中，你不可能就这些解决方案中的任何一个提出有效的论据。
根据上下文，所有这些解决方案（以及更多解决方案）都是合理的。它们都有权衡：初始实施工作，运行成本，维护，监视。但是我经常看到工程师选择过于复杂，过于昂贵的选项，因为愚蠢的简单解决方案使他们感到不安。
当您有很多可用的解决问题的方法，而简单的方法使您感到不安时，您应该退后一步，考虑一下原因。通常，是否有一个合理的原因解释为什么简单的解决方案不起作用？如果没有的话，您就可以省去实施复杂解决方案的麻烦，而您的队友则可以维护它。
到目前为止，我仅讨论了编写新软件所涉及的权衡。但是主要的罪过是拒绝现有代码中的缺陷。
技术债务有其合理存在的原因。
您有多少次听到一个队友说他们正在重构：却造成失控并完全停止了其主要目标的进展？这些重构中有多少最终在完成之前就被放弃了？导致同一事物的两个并行模型的频率如何，使代码库更加混乱？（重构还不如不重构，不折腾，折腾前先搞清原因再入坑，不要等入坑以后才知道原因）
容忍瑕疵还有其他优点。旧代码的原始作者可能做出了完美的权衡，但您无法从自己的位置或角度看到这一点（每个人的视角不同）。您的不安是没有根据的，更类似于初级工程师或学生的不安。始终考虑直觉是错误的可能性。重写初级工程师的代码使人沮丧。如果大三学生做了不正确的事情，请不要自己重写。
如果您要完成任何事情，您必须能够容忍缺陷。我们做过的任何事都不完美。尝试这样做是愚蠢的事,放手吧。