通常設計技術用於讓系統更靈活，但最後卻變得更難使用。原因之一是明確性是設計中經常被遺忘的特性。

思考如何視覺化和降低耦合。

為了宣傳我們的書籍《規劃極限編程》，接受了 Pearson 的訪談。我們討論了 XP 的背景以及規劃在 XP 專案中扮演的角色。

克雷格在專欄中的觀點探討了開放封閉原則和受保護變異的重要性，以及為什麼 Parnas 的資訊隱藏不只是封裝。他也提供了一些實作受保護變異的方法。

我學到的第一個教訓之一，就是永遠讓使用者介面程式碼與其他任何東西分開。這不僅仍然是一個好建議，而且令人驚訝的是，它經常被遺忘。

2001 年 1 月，兩個 Java 工具跨越了重構的界線。現在 Java 中的重構有了強大的工具支援

2001 年，當我前往 Snowbird 參加導致敏捷宣言的會議時，吉姆為他正在撰寫的一本書採訪了我。這提供了我對極限編程的思考，以及幾天後我們稱之為敏捷軟體開發的觀點。

2001 年 2 月，一群十七人齊聚猶他州雪鳥鎮，討論輕量級方法的新風格。其中一項成果是創造「敏捷」一詞，代表軟體開發中新一代的敏捷流程。我們也共同撰寫了 敏捷軟體開發宣言，描述這些敏捷方法的價值觀和原則。吉姆·海史密斯和我為《軟體開發》雜誌撰寫了這篇文章，進一步說明宣言。

有時，在軟體中避免重複的簡單規則，會如何引導出良好的設計，這一點相當引人注目

自新千年開始以來，我們一直在執行一個有趣的 XP 專案。它之所以有趣，不只是因為它是 Thoughtworks 的第一個 XP 專案，還因為它的規模：大約有 50 人參與。在這裡，我們討論如何執行這個專案，重點放在單一迭代中需要執行的活動，以及各個子團隊如何圍繞該迭代運作。

XP 其中一個有吸引力的地方在於，它對執行 XP 應該做什麼給出了明確的說明。此外，這組實務經過仔細設計，以相互配合。移除任何一項都會造成嚴重的後果。然而，XP 和其他敏捷方法的原則之一是它們具有自適應性：也就是說，你應該在開發專案時變更流程。這個概念如何與 XP 的嚴格實務相符？