軟體成功的 3 / 7 法則

        今年三月底，為了挽救公司的新產品，我臨危受命飛往馬來西雅。也是第一次我才一下飛機，透過越洋國際電話，就決定放生一位團隊同事。

        下令放生之前，我寫了封信，跟團隊談談我心中認為『成功的系統』的關鍵要素：

        「嗨， 昨天『Ｘ系統』錯帳的事情，大家辛苦了。尤其感謝那些在公司待很晚、待命到問題解決的同事仁們。  

        我常覺得：『人的成功，若是三分天才 + 七分的努力才能獲得，那軟體系統的成功，就是三分技術 + 七分的紀律與嚴謹驗證的態度。』 

        技術再新再好，頂多創造三十分的價值。但是就算技術老舊，只要有紀律和不斷測試驗證，就能替使用者創造出七十分的價值。 

        去年有次晨會我就跟大家說過，軟體就是比玻璃還要易碎的東西，打破一個玻璃杯你還要花相當的力氣，但是弄壞一個系統，你只要手指不小心在鍵盤上發抖一下，大小寫拼錯或是加減打反，就壞得一踏糊塗，不費吹灰之力。 

        所以雖然人人都可以寫軟體，千萬不要以為寫好一個不出錯的軟體系統很容易。 

        我所知道軟體界很優秀的人，都不是什麼技術很高、很會玩弄或破解什麼別人看不懂的技術，而是那些態度嚴謹、永遠想著如何避免犯錯的人，這些大師創造出許多軟體工程的方法論，就是這些人知道人一定會出錯，所以想破頭在思考如何用流程來預防。 

        這次『Ｘ系統』的錯誤的原因，是在開發『Ｙ功能』第二階段的期間， 3 / 19 日那天『Ｘ系統』的『Ｚ程序』有附件內的修改： 將原本判斷財務金流增減的那段 IF 條件中的⋯⋯（略）。

        而移掉這個 IF 判斷的條件，卻造成這『Ｚ程序』再也無法判斷『Ｘ系統』的財務金流，而讓所有的使用者的帳都損失。 

        這個出乎意料的順手改，所造成的問題之明顯，可以知道修改的人改完之後絕對沒有測過！ 

        我不是反對修改，原本就正常的東西你若有心想把它改得更好，我也很鼓勵！就像我們最近積極地 refactor 一樣。 

        這件事最大的錯誤，不是『修改了本來正常的東西』，而是『改了卻沒有測』！沒有驗證！沒有讓任何人知道！  

         如果你太忙，不打算測，那我寧願你不要改！ 尤其改的還是 DB 內跟錢有關最重要的『Ｚ程序』！ 

        我對這種嚴謹的要求，絕對不是現在給大家放馬後炮，當初要上 report pre-gen 這個改善校能的機制，前前後後跑了多少次驗證？ 還專門寫了一支程式（略）每天跑各種查詢條件來跟 on-fly 的版本做交叉比對，確定好幾天都沒錯誤才敢給 User 使用？不只如此，而且還特意保留一個切換功能給大家在緊急的時候可以 runtime 切換 pre-gen / on-fly 兩種版本。 

        而且，pregen 還不是我自己開發的，上述我做這些都是為了幫別人把關驗證。你們對這整套系統前前後後有比我熟嗎？若沒有，那理應比我更小心更謹慎啊！怎麼可以比我不熟，卻還可以比我更鬆懈隨意呢？ 

        你盡力測但仍有 case 沒測到，這大家可以理解。但改了卻完全不測，認為自己不可能會修改錯的人，能力太強了，應該去 Google，不應該跟我們在這邊浪費生命。 這也是我當時讓 EXX 去找更好的發展的原因。  

        記住：你懂的技術再多再新，頂多創造三十分的價值。但是就算技術老舊，只要有紀律和嚴謹的態度，就能替使用者創造出七十分的價值。 

        我不想讓這件事造成以後大家都不敢修改任何東西，害怕 refactor 。 

        所以不要弄錯焦點，我不責怪修改，我要責怪的是『改完卻不測』！

Best Regards」