作者：查德·拉·瓦因（Chad LaVigne）
軟件架構師解決了很多非常困難的問題，但是也會去解決一些相對容易的問題，對於簡單的問題，不要使用複雜的解決方案。這個建議聽上去顯而易見，但是遵循卻不容易。軟件設計者都是聰明人，真的很聰明，但是出於炫技心理，很容易陷入“殺雞用牛刀”的誤區（simple problem-complex solution trap）。如果發現自己正在設計一個非常聰明的解決方案，也許應該對此保持警醒自覺（self-aware），停下來想想：解決方案是否對症？如果答案是否定的，則需要重新設計中的各個選項。對簡單問題要保持簡單的解（keep the simple stuff simple）。架構師展示才華的機會多的是，只要真正的難題出現，總有這樣的機會。
但這並不是說不要追求漂亮的解決方案，而是指，如果我們的任務是設計這樣的系統；它只需要支持銷售單一種類的基於SKU（Stock Keeping Unit，最小存貨單位）的商品，那麼，設計成支持可動態配置產品層次結構的系統可能就是糟糕的主意。
爲複雜解決方案付出的真接成本可能看上去很小，但是其潛在成本要大得多。和開發層面的過度工程一樣，架構上的過度工程（over-engineering），會導致許多問題，但其帶來的負面影響則往往會成倍增加。錯誤的架構設計決策會使系統實現困難且不易維護，最糟糕的是，實現是無法逆轉（reverse）的。在往前做出超越系統實際需求的架構決策時，不妨自問：照此實現之後，如果要再退回去會多麼困難？
爲有問題的解決方案付出的代價，不僅僅只是在實現和維護上。在簡單問題上耗費了過多時間，則留給解決複雜問題的時間相對就少了。不當的架構決策陡然間導致了範圍的蔓延，往項目中增加了不必要的風險。如果你能保證其他人也不會這麼做，你的時間利用率就會大大提升。
架構師會從主觀的判斷或潛在不確定需求出發，產生調整解決方案的強烈衝動。請記住一點。試圖猜測未來的需求時，錯的概率是50%，錯的很離譜的概率是49%。今天只需要解決今天的問題就好。把應用發佈出去，從反饋中生成真實的需求。由於己經創建了簡單的設計，當真實需求到來時，要將之整合進來就會更加容易。如果剛好運氣不錯，先前猜測的需求在下一個發佈版本中變成了真實的需求，那現在更是成竹在胸了，與之前不同的是，現在可以估算出更合適的時間分配了，因爲這次它己經變成真實的需求。不知不覺間，團隊就會獲得“能做出精準的預估，按時完工”的好名聲了。