日常生活中观察到的现象为例说明了马汀的错误：餐厅以 4.99 美元的价格向我出售培根和鸡蛋，这并不意味着它们就值这个价，不管是不是从普遍意义上来看。事实上，对于餐厅来说，这些培根和鸡蛋的价值低于 4.99 美元，对于我来说，它们的价值高于 4.99 美元。

就像 “交换必然是等价交换” 一样， “货币是价值尺度” 同样是由来已久的经济学谬误。

不幸的是，它被误解扭曲了。许多软件工程师将这一准则理解成"你永远不应该优化代码！"，认为没有必要进行优化。 Tony Hoare 和 Donald Knuth 的真正意思是，代码微优化（例如，一条特定语句消耗多少 CPU 周期）之前，开发者应该担心其他问题。而且，原话并不是说："在开发的早期阶段，关注程序的性能是有害的。" 他只是反对过早的优化。 以下几点理由，可以解释为什么不能忽视软件性能。程序员正确的做法应该是，在软件开发的早期阶段，就关注性能问题。 （1）性能问题不容易在软件开发的最后阶段解决。20％的代码占用了80％执行时间，它们可能散布在整个源代码中，不容易一次性修改解决。 （2）许多工程师相信，到软件发布时，CPU 的性能将会提高，以弥补部分代码的性能低下。尽管在1990年代确实如此，但在最近十年 CPU 性能非常有限。 （3）软件工程师认为，他们的时间比 CPU 时间更有价值。因此，浪费 CPU 周期以减少开发时间是对的。但是，他们忘记了，用户的时间比他们的时间更有价值。 （4）优化可能会导致产品延迟进入市场，并降低利润，这是正确的。但这种想法忽略了性能不佳的产品可能很难销售，尤其是在市场竞争激烈的情况下。 （5）有些程序员认为，几乎没有必要确保在软件的设计阶段，就使用最佳算法，先实现功能再说，因为以后总是可以替换更好的算法。所以，无需担心软件在开发阶段的性能，以后可以通过更好的算法对其进行提高。不幸的是，更好的算法在后期不一定可以实现，而且代码往往因为牵扯太多，无法轻易替换其中某个部分。