接触极限编程一段时间，找到以下四点反驳它的理由：
[1]代码质量
极限编程运用测试驱动开发（TDD），其理论基础是需求应该是可测试的，其目的在于保证软件系统的正确性和健壮性（测试用例足够充分的话）。可以这么认为：极限编程关心的是结果，不关心过程。因此它忽略了软件系统的结构性和开放性。我们知道结构性有助于修改，开放性有助于扩展，而极限编程却放弃这种追求，导致的结果就是产生一大堆丑陋的代码，而且随时有可能被彻底抛弃。
极限编程解决效率，结构性和开放性问题的对策是重构，它宣称重构无处不在，但是重构是一种补救的方式，为什么不在设计初期进行预防呢？极限编程回避不了这些问题，而只是将它们推到了后面的阶段，但是付出的代价可能会更高。
[2]工作进度
极限编程直接将代码作为文档，弱化传统文档的作用。既然如此，那么代码就应该有规范的格式和详尽的注释，以便提高它的可读性，但是由于极限编程采用的是团队合作方式，代码规范很难得到统一。那么通过注释吧，可是极限编程认为注释是一种负担，无法适应频繁修改的代码。
极限编程解决沟通问题的对策是结对编程，它认为频繁的沟通胜过面面俱到的文档，但是文档是永久的，沟通却是短暂的，大家可以看同一份文档，却要进行多次两两沟通，所需时间也许并不比写文档的时间少。更糟糕的是，经常地切换搭档将极大地破坏工作的延续性，只能拖慢进度。
[3]工作量
测试驱动开发具体应该怎么做呢？测试驱动决不是说代码从测试写起，在写测试用例之前，肯定要对需求有完整的了解，否则测试无从写起，其实这就是需求分析以及设计，还是与瀑布模型一样的流程，只不过没有文档化而已。唯一不同的是极限编程要求需求都是可测试的，因此要把这些需求翻译成系统测试用例，集成测试用例，和单元测试用例。由于写程序必须同时写它的测试，因此如果改程序则必须改测试，这将达到两倍的工作量。
[4]目的
极限编程认为需求是不断变化的，因此软件能满足当前需求就好，没有必要构造框架之类可复用的东西，它认为这是一种过度设计。这种思想是极端的，因为框架就是为了解决需求变化问题而出现的。举个例子，MFC就是一套框架（尽管我厌恶它），但是基于MFC却可以开发网络，多媒体，数据库甚至游戏应用程序。面向对象的目的就是为了复用，而且好的框架能够做到隔离变化，依赖抽象，如果认为软件系统的一切东西都是暂时的，无疑是与面向对象思想背道而驰的。