在編寫軟體時，若要說是否有一個讓人特別著迷且容易獲得成就感的過程，那麼設計架構應該也是其中一個。好的架構能讓日後維護更加方便，不好的架構只會讓這個專案難以擴充、無法成長。所以在設計架構時，程式設計師們常常無不絞盡腦汁地思考要怎麼設計出一個最好的架構。這是一件好事，但任何事物總是過猶不及，若是想的太長遠，就容易產生 Over Design，甚至設計出未來根本用不到的架構。

在寫軟體時，總會容易陷入一個迷思，就是要寫出一個「完美」的架構，然後一勞永逸。但是追求「銀子彈」這件事是種危險的念頭，或許真的有一枚銀子彈，但是或許現況只需要一般的子彈就夠，之後也不用再射擊，這時候花費大量成本去打造銀子彈反而是一種浪費。

會有這種思維通常在於希望架構永遠不變，但這都是不切實際的。事實上，當架構不適用於當前的狀況時，就應該勇於改變。如同「流水不腐，戶樞不螻」，好的軟體應該在於經常變動，不要將程式碼視為金石，而要敢於去更動。只要願意且敢於修改既有的程式碼，那就比較不容易有 Over Design 的程式碼。

在實作時，只要針對當前的需求去設計，在還沒有需求產生的部分，就先不要去實作它。尤其是需要花費大量時間和精力去思考的設計，若只是為了當前不存在、且未來是否可能會遇到都不知道情況，就可能是一種浪費。

在設計架構時，要釐清需求。舉例來說，若是近期軟體都只會面臨 100 人的連線數，卻去不斷思考 10 萬人的連線數該怎麼處理時，這個設計就不符合需求。比較好的方式是先確認至少在何時之前都只需要最多 100 人的連線數，然後只針對這部分去設計架構、測試，並告知軟體目前就只能承受最多 100 人的連線數，若是要超出這個負荷，就要另外再花更多成本去研發；如果要在現在就開發出 10 萬人的連線能力，就勢必會延遲讓軟體釋出的日程。讓業務方暸解限制，好好思考到底有沒有需要這麼大的連線數。

除了開發方和業務方之前釐清需求外，開發內部也是同樣要這樣思考的。到底資料庫的正規化是做到多細、到底現在是否要客製化框架還是套用現成的、到底有沒有需要把有限的時間投資在效能的改進上⋯⋯等等。先以符合當前的需求去設計，並在評估未來可能會遇到的情況時，根據可能性與成本去作權衡，做出適合的設計，並且明確讓相關人員暸解到當前的限制，以及未來什麼需求確定後，需要再另外耗費研發成本去改變當前的設計。

開發軟體，有時候不只是單純追求完美的技術境界，更多是多方面的拉拔與平衡。所以沒有最好的設計，只有最適合當前的設計。