Dan North最近发表文章《误导的艺术》，着重讨论了机会成本的影响。机会成本通俗地来说是指你针对某个情况作出来一个选择，然而有时候，可能还有一个更好的选择被放弃了。特别对于软件工程师而言，机会成本是个不得不说的故事，毕竟在每天的工作中，他们需要不断做出各种决定。
Dan认为，软件工程师在工作中总是面临着很高的机会成本。为了证明他的观点，他提议做一个试验：
试一下这个试验：想一个你在开发软件的时候会用到的技术或者实践，或者就那个你最喜欢的实践吧，容易吧？好吧，第一步：你为什么用它？有什么好处 呢？可能你想到了一些答案，那么就先写下来。现在，第二步：如果你不用那个技术或者实践，有哪些别的可供选择的方案吗？也请写下来，并且列出每一个的优缺 点。
Dan以那个在他看来是他遇到过的最被盲目推崇的实践之一：TDD(测试驱动开发)为例进行了阐述。
Dan认为，倡导TDD的那些理由，诸如为了系统稳定和应对变化，涌现式设计，自动化测试以及测试即文档等，背后也有着机会成本。比如，对于财务交 易系统那一块而言，使用一些草图来理解系统可能会很有用，而不需要可能会导致很高成本的TDD了。至于涌现式设计，TDD就像在查找最大值，然而寻找最佳 的解决方案可能需要彻底的重新思考。而测试即文档则说不定会导致很多不必要的不同声音，反而让人搞不清真正有用的文档在哪里。
Dan最后总结了他的文章并且建议：
所以不要被表面利益所迷惑，在你做每个决定的时候，都要好好权衡机会成本，因为不管你看得到还是看不到，机会成本都在那里，不多不少。但如果你能学会识别这些，你也能更上一层楼。
有些读者同意Dan的观点。Gene Hughson解释道：
很棒的文章。尝试任何事情，不管是新技术还是技巧，如果不去考虑成本和收益，那么将是个灾难。
然而，也有些读者有着不同的意见。比如，Sam Weisen就在他的评论中提到，Dan的文章这样去讨论TDD是有失公允的。
我恐怕不得不说，你误解了TDD，你对TDD的攻击是毫无意义的。你的有些观点可能不错，但淹没在你的长篇大论之中。
Liz Keogh则支持Dan的观点和提议，他觉得敏捷开发的信徒们应该更加开放地去聆听别的意见：
我发现评论中的很多人都犯了“不是真正的苏格兰人（No True Scotsman）”的谬误，也就是说如果某个事物对某人不起作用，那么一定是那个人用错了。我在一些敏捷博客中也都发现过这种情况，特别是提到TDD和 Scrum的时候。其实很多情况下，TDD并不是最合适的选择，比如统计工时的程序、修改一个紧急的产品缺陷。当然也有不少情况，TDD是比较合适的，但 却不是最佳选择。
看来很难让每一个人都赞同Dan的观点，特别是有关于TDD的，那么也可以此为契机从另一个角度来审视这个问题。Justin就提到：
谢谢你让我们看到、思考这些盲点：这篇文章迫使你走出你的思维定式，重新审视你的想法。我相信，很多成功的团队都是一步步从那些方法和实践集中提取部分内容，组成自己的方法，从而构建一支高效的团队。