設計耐力假說

設計良好的軟體是否值得花費心力？

我時不時會間接討論良好的軟體設計是否值得進行。我說這些討論是間接的，因為我認為我從未遇過有人說軟體設計毫無意義。通常會以「我們真的需要快速行動才能在明年達到目標，所以我們正在減少 <某項設計活動>」的形式表達。

其中有一個概念是，設計是可以為了更高的速度而捨棄的東西。事實上，我已經多次遇到這樣的印象，即設計工作之所以被容忍，是因為它讓程式設計師感到滿意，即使它降低了速度。

如果投入設計工作會降低程式設計的效率，我會反對它。事實上，如果真是這樣，我想大多數軟體開發人員都會反對設計。開發人員可能會對什麼才是好的設計有不同的意見，但他們支持他們所支持的任何好的設計品牌，因為他們相信它可以提高生產力。（這裡的「設計」指的是前期設計或敏捷方法，例如 計畫或演化設計。）

設計活動確實需要花費時間和精力，但它們的回報是讓軟體更容易在未來演化。忽略設計可以節省短期時間，但這會累積 技術債，這會在稍後降低你的生產力。投入精力設計軟體可以提高專案的耐力，讓你能夠持續更長的時間。

以下的偽圖表是一種視覺化方式。

偽圖形繪製功能（累計）與時間，針對兩個假想的刻板專案：一個有良好設計，一個沒有設計。沒有設計的專案不會在設計活動上花費任何精力，無論是前期設計或敏捷技術。由於這些活動沒有花費任何精力，因此這個專案最初會更快產生功能。

沒有設計的問題在於，由於沒有將精力投入設計，因此程式碼庫會惡化並變得更難修改，這會降低生產力，也就是線的梯度。良好的設計會讓生產力保持更穩定，因此在某個時間點（設計回報線）它會超越沒有設計專案的累計功能，並持續表現得更好。

我稱之為假設，因為這是一個猜想，沒有客觀證據證明這個現象實際上會發生。在科學術語中，這不是一個很好的假設，因為很難測試。我們無法衡量生產力，也無法衡量設計品質。

但儘管它只是一個假設，它也是許多人的公理，包括我自己。我們可能沒有客觀證據證明這個效應會發生，但我們許多人認為這解釋了我們在現場看到的現象。對我來說，這是一個公理，因為它是支撐我整個軟體設計寫作生涯的假設。如果設計沒有以某種方式實際提高生產力，那麼我大部分的著作都是沒有價值的。

我相信對許多人來說，將假設視為公理聽起來很奇怪，但這是一件很常見的事。我認為我使用自己的判斷來評估假設是否為真，但可以在不忽略假設的客觀弱點的情況下這麼做。我希望能找到一種方法來證明它，而且幾乎可以反駁它。

這個假設有一個推論，來自設計回報線。如果你的初始版本的功​​能低於設計回報線，那麼可能值得用設計品質換取速度；但如果它高於這條線，那麼這種權衡就是一種錯覺。當你的交付高於設計回報線時，忽略設計總是會讓你延後出貨。在技術負債方面，這就像貸款但沒有使用本金太久，以至於在你使用它時，你已經支付了更多的利息。

這引發了一個問題，這條線在哪裡。即使是接受設計耐力假設的人，對於回報線在哪裡也有很大的、重要的分歧。我的觀點是，它比大多數人認為的要低得多：通常是幾週而不是幾個月。但同樣地，這只能是一個判斷。

這會導致技術債的後果。技術債務是一個很棒的類比，我經常使用它。但設計回報線提醒我們，借入技術債務只值得做到某個程度。我們不僅要考慮交付價值是否大於利息支付，我們還必須首先判斷交付是否高於回報線。