接觸極限編程一段時間，找到以下四點反駁它的理由：
[1]代碼質量
極限編程運用測試驅動開發（TDD），其理論基礎是需求應該是可測試的，其目的在于保證軟件系統的正確性和健壯性（測試用例足夠充分的話）。可以這么認為：極限編程關心的是結果，不關心過程。因此它忽略了軟件系統的結構性和開放性。我們知道結構性有助于修改，開放性有助于擴展，而極限編程卻放棄這種追求，導致的結果就是產生一大堆丑陋的代碼，而且隨時有可能被徹底拋棄。
極限編程解決效率，結構性和開放性問題的對策是重構，它宣稱重構無處不在，但是重構是一種補救的方式，為什么不在設計初期進行預防呢？極限編程回避不了這些問題，而只是將它們推到了后面的階段，但是付出的代價可能會更高。
[2]工作進度
極限編程直接將代碼作為文檔，弱化傳統文檔的作用。既然如此，那么代碼就應該有規范的格式和詳盡的注釋，以便提高它的可讀性，但是由于極限編程采用的是團隊合作方式，代碼規范很難得到統一。那么通過注釋吧，可是極限編程認為注釋是一種負擔，無法適應頻繁修改的代碼。
極限編程解決溝通問題的對策是結對編程，它認為頻繁的溝通勝過面面俱到的文檔，但是文檔是永久的，溝通卻是短暫的，大家可以看同一份文檔，卻要進行多次兩兩溝通，所需時間也許并不比寫文檔的時間少。更糟糕的是，經常地切換搭檔將極大地破壞工作的延續性，只能拖慢進度。
[3]工作量
測試驅動開發具體應該怎么做呢？測試驅動決不是說代碼從測試寫起，在寫測試用例之前，肯定要對需求有完整的了解，否則測試無從寫起，其實這就是需求分析以及設計，還是與瀑布模型一樣的流程，只不過沒有文檔化而已。唯一不同的是極限編程要求需求都是可測試的，因此要把這些需求翻譯成系統測試用例，集成測試用例，和單元測試用例。由于寫程序必須同時寫它的測試，因此如果改程序則必須改測試，這將達到兩倍的工作量。
[4]目的
極限編程認為需求是不斷變化的，因此軟件能滿足當前需求就好，沒有必要構造框架之類可復用的東西，它認為這是一種過度設計。這種思想是極端的，因為框架就是為了解決需求變化問題而出現的。舉個例子，MFC就是一套框架（盡管我厭惡它），但是基于MFC卻可以開發網絡，多媒體，數據庫甚至游戲應用程序。面向對象的目的就是為了復用，而且好的框架能夠做到隔離變化，依賴抽象，如果認為軟件系統的一切東西都是暫時的，無疑是與面向對象思想背道而馳的。