蓋爾定律 (Gall's Law) 來自 John Gall 在 1975 年寫的《Systemantics: How Systems Work and Especially How They Fail》。
Note
雖然軟體工程上很常聽到類似的原則，但這本書不是專談軟體工程方面的系統，而是泛用性的系統理論。
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
一個能正常運作的複雜系統，無一例外，都是從一個「能運作的簡單系統」逐步演化而來。一個從零開始被設計出來的複雜系統，永遠不會真的運作，而且也無法靠事後修補讓它變得可運作。你唯一能做的，是回到起點，從一個「能運作的簡單系統」重新開始。
知名失敗案例
- 美國的 HealthCare.gov 於 2013 年 10 月 1 日首次上線即崩潰的事件。
- Netscape 花了 3 年的時間，放棄 Netscape 4 的原始碼，重寫開發 Netscape 6。花費的時間導致把市場機會都讓給微軟的 IE，2000 年 11 月發佈後也遭遇系統問題，最終公司倒閉。
誤解
有些管理人，或甚至是不負責任的工程師，會把這個理論扭曲為「不需要先行設計」或是「之後再重構就好」。但是，如果系統之後要能夠演化，前提是系統必須要被設計成有能夠演化的條件，從軟體開發的角度來說就是可維護性和可擴展性。
也就是說，系統仍然需要先行設計，但是要基於簡單和可演化這兩個原則。特別是不要在未經驗證的假設下進行過度設計。這也符合 XP（Extreme Programming，極限程式設計）的簡單設計原則。
是的，但是我們知道總有一天會需要資料庫，會需要 ORB，也總有一天得去支援多客戶端。所以，我們現在就需要為那些東西做好準備，不是嗎？
XP 團隊會對此進行認真的考慮。他們開始時會先假設方案不需要那些基礎設施。只有在有證據或至少有十分明顯的跡象顯示現在引入這些基礎設施會比繼續等待更划算時，團隊才會引入這些基礎設施。
- 《無瑕的程式碼 敏捷完整篇》P.21
又例如：明明還沒受到市場青睞，就先使用微服務架構以解決尚未出現的高流量需求，但這也不代表單體服務架構就可以隨便寫。