围绕软件开发实践和方法的宗教战争中有很多教条。阶段门方法在管理软件开发的风险方面有效吗，还是仅仅是风险管理歌舞伎？TDD真的有利于更高质量的软件吗？结对编程是代码审查的高级替代品，还是只是提高咨询率的一种方式？我要说的是，虽然缺乏科学证据来决定这些主张，但有两个一般原则可以帮助我们选择好的实践，同时提高我们交付的软件的价值:减少周期时间和增加反馈。
迈克尔·费哲做了如下观察:
我认为，最终，我们不得不承认开发人员的技能是一个比语言选择或方法上的细微差别重要得多的变量。坦率地说，我想我们都知道这一点，但我们似乎有一种错觉，认为它们是调整的主要旋钮。也许这是一种根深蒂固的观点的延伸，即从经济的角度来看，如果人们可以互换，那将是理想的。
事实上，软件项目是复杂的系统，而不是常规环境，这导致了另一个问题——收集技术、实践和方法实际有效的数据极其困难，以及在收集数据的环境之外推广这些数据几乎是不可能的。
在他的优秀著作《软件工程的妖精》中，洛朗·博萨维特对软件开发民间传说进行了毁灭性的攻击，如“变化的成本”(或“缺陷的成本”)“曲线”，声称开发人员生产率的变化是一个数量级，确定性锥的思想，以及软件开发方法学的许多其他基石。他表明，这些理论——以及许多其他理论——依赖于非常小的数据集，这些数据集要么是从对计算机科学学生进行的非正式实验中收集的，要么是从不可能得到有效控制的项目中收集的。构成这些主张基础的研究组织通常在方法上不合理，数据分析不佳，最令人震惊的是，这些发现远远超出了它们的适用范围。
因此，不可能认真对待关于敏捷开发实践是否比瀑布开发实践更好的任何一般说法，反之亦然。“思想领袖”的直觉也是一个糟糕的向导。正如卡尼曼所说，“人们对直觉的信心并不能可靠地指导他们的有效性……在评估专家直觉时，你应该始终考虑是否有足够的机会学习线索，即使是在正常的环境中。”正如本·巴特勒-科尔在他的配套文章《为什么软件开发方法会失败》中指出的那样，引入一种新方法的行为可以产生该方法的采纳者想要带来的一些结果。但对我来说，这是决定性的:对我们来说，实践持续改进，学习如何作为团队或个人变得更好，以及获得能够成功创造伟大产品和服务的技能几乎是不可能的——除非我们专注于让反馈回路尽可能短，以便我们能够实际检测相关性，并辨别因果关系。
