搞 IT 這行一定會碰到技術和需求 (requirement) 相衝突的時候，有些來自業務部門的需求要嘛是天馬行空、不然就是疊床架屋。以技術的角度來說，往往不是做不到，而是值不值得做的問題。

學界訓練技術人材，是教導學生找出好的解答，就算不是最佳解，至少也應該要找出次佳解 (suboptimal solution)。”Dirty-hack” 並不在學校教導的範疇內。即便進入業界，所謂的技術大師也往往是因為能夠提出漂亮的架構或是清楚的系統介面而受到尊敬，而不是因為 “總是能讓一個陳舊的系統還可以運行” 而受人稱道。如果說 MBA 畢業生其實只要學會在一上任就喊 “組織重組” 就可以畢業，那資深系統架構師或許也只需要會 “reboot”, “re-install” 和 “re-architect” 就可以混口飯吃了。

可是偏偏做生意是沒有規則的，需求 (requirement) 是沒有止盡的，永遠會有一個新的生意需要 Dirty hack，永遠會有一個新客戶想要而當初沒考慮到的需求。這也是跟做一個拋棄式的網站最大的不同，因為拋棄式的網站沒有維護的問題、沒有陳年的商業邏輯、沒有新需求注入。

先前我認為好的架構是系統穩定最重要的因素，但後來發現，商業網站的程式碼和商業邏輯是切不開的，並沒有一個架構有辦法讓商業邏輯自成一格。除非做生意的變化種類減少，不然網站的程式複雜度就不可能會減少。一旦邏輯複雜，就只有走向 dirty hack 一途。

某種程度上這也解釋了為什麼大公司沒辦法像新創小公司一樣快速產生網站；扣掉繁複的內部流程，程式設計師要擔心的不是 “我加了什麼新功能?”，而是 “我搞爛了什麼舊功能?”

純技術性的想法是，拋棄舊的架構，在新的架構把所有東西重寫。不過走這條路要成功是難上加難，想像你必須抄寫一張已經被立可白塗抹了十幾年的手寫草稿，要怎麼知道現在寫在上面的東西，真的是它表面上的意思呢?

重新架構的另一個問題是，這段時間你的研發能量就被佔滿了；你在原地踏步，只希望未來可以跑得比競爭者快 — 我希望你能活到那時候。

就因為這其實並不是個簡單的問題，所以才讓能夠妥善處理這種問題的公司能夠脫穎而出吧。不過，這樣更好玩，不是嗎?