段引入一个缺陷的话，那么在项目的分析阶段发现这个缺陷会比允许这个错误直至进入设计阶段才被发现节省约10倍资源。但是Boehm在此做了一个在新千年的头十年中未必依然正确的基本假定：仅当该缺陷在生命周期某阶段发生时可通过某种方式加以鉴别，那么这种数量级增长关系图才是相关的。在今天的环境中，这个前提假定在许多商业条件下都是不成立的。比如，当Bill Gates阐明对于浏览器IE的需求时，可能他会说“就象Netscape Navigator那样，但要更好”，可能Netscape的Marc Andreesen也会这样想：“我希望使Navigator就象Mosaic一样，但要更好。”但是当Tim BernersLee在构建WWW的初始版本和浏览器的第一个草样时又该如何考虑呢?让他写出详细需求的意义何在呢?
与此同时，重方法的倡导者争辩说，如果一个缺陷在开发阶段就被发现，那么就不应当责备引入该缺陷的个人，而应重新检查允许该缺陷发生的过程本身。但此处又有一个基本假设，也就是说，我们值得投入资源在鉴别一个过程中潜在缺陷的唯一理由是我们希望再次使用同样的过程——因为我们的下一个项目将会与上一个项目足够相似，很自然就应使用同样的过程。但是现在事物变化是如此之快，以至于完全不能保证第N+1个项目会与第N个项目有任何相似之处。因此，昨天的过程可能不得不为了明天的需求而发生实质性变化，换言之，也许只有投资于过程中的重要缺陷才是值得的，因为一些细节仅针对某个特定项目才有意义。
当然，仍然有一些环境需要我们继续依赖于旧的、基本的软件工程原理，在这些环境中重方法被证实依然正确。但是我们应当扪心自问，隐藏在这些原理背后的前提假定是否依然合理。对于许多今天的项目而言，一些根本性的前提假定需要加以改变，而轻方法将是具有最优性能价格比的方法。
可以看出，轻方法的基本思路是试图在项目范围、成本、时间和质量之间达成一种平衡，其关键是在足够的管理可见度、足够的灵活性和足够快的开发速度以完成工作之间找到这种平衡，必须严格审查你想要对项目加入或删除的控制手段的价值何在。
尽管我们可以将某个公布于众的开发方法作为基础进行裁剪，但必须深入理解你要执行的每个步骤的理由，尤其在项目的初始规划阶段，就应明确定义开发方法，确保项目团队成员的参与和认可，并以满足项目的商业需求为目标。