極限編程潛在的中心前提就是兩種思想比一種要好。兩個程序員並排坐在一起，一個編程，另一個逐塊逐行地挑刺。這樣做的原因很明顯，如果在鍵盤上操作的人是司機的話，那麼他旁邊的人就是領航員。當中沒有誰是上司——他們的地位是平等的，角色是相輔相成的。極限編程讓人震驚的地方就是實際起作用的技術。
由於有回報，極限編程已經在前端開發圈裡站穩了腳跟。把兩個身價不菲的開發者安排在一台機器上，似乎看起來是很荒謬的，但是事實證明並非如此。在極限編程中，大部分的程序缺陷在產生之前就被扼殺了；在編寫低速代碼時，最優化就出現了；知識相互交流；並且團隊關系也就產生了。
依我的經驗，這種現象還沒有滲透到數據庫層的開發中。我注意到在有的團隊中，一個人編寫存儲過程，第二個人編寫數據傳輸系統（DTS），第三個做體系機構，而第四個人為中間設備界面做評注。每個人都孤立地創作所需的對象，而且幾乎不會對代碼進行檢查。也許設計師規定Sproc98765接受特定的參數，並返回某個結果；然後團隊中的其他成員就與之相對應。在任何一個嚴謹的開發組織中，檢查代碼和再因子分解是一個項目不可或缺的部分，但是由於某些奇怪的原因，它們並沒有延伸到數據庫中。
我無法理解這點。也許我們共同蒙蔽了管理者，讓他們認為我們對數據庫已經無所不知了。或者我們服務的定價太高，以至於會計人員都因為核算每個星期再因子分解和極限編程的花銷而氣喘如牛了。
舉個例子來說，在一個包含了400個表格和1,600個存儲過程的數據庫中，我得到的每一個結果都是正確的幾率是多大呢？即使有時候會出現那樣的情況，那麼下一次一個部門或客戶需要知道某個表中的新加的列，我就必須重新訪問不計其數的程序、用戶自定義函數（UDF）和查看——而且這只說明了表格結構的變化。
如果可能的話，我鼓勵您嘗試用極限編程方法去解決當前面臨的SQL Server中的問題。對於這種方法，可供選擇的包括一個復雜存儲過程的最新進展，對一個低速程序再次進行因子分解和使一個查看最優化。至少嘗試一下，然後讓我知道它是怎麼為您所用的。
