為什麼老是有一樣的出包

一言以蔽之:人們很難從別人的錯誤中吸取教訓。

Lessons Learned

我們做過很多專案、設計過許多產品,也出過很多bug,每一次有issue,事後老闆都要我們寫檢討報告,說明(包括但不限於):

  • 發生什麼事
  • 根因是什麼
  • 為什麼事前無法避免
  • 以後該如何預防

其實老闆就是希望我們不貳過,犯過的錯誤,不再重犯。通常在這份檢討報告中,我們都會發展出很多系統,例如check list,在檢查清單中加入一層又一層的check item,也會開發新的simulation algorithm和tool,讓後人可以用這些工具來檢查已經發生過的issue。

以前我總是對發展出來檢查方法感到驕傲,因為我們距離bug-free的理想要更近了一步。然而這麼多年過去了,我們還是一直在出bug,而且很多都還是stupid bug的重蹈覆轍。反倒是我們的check list越來越繁重,要知道每一個check item都是要成本的,模擬需要tool license、computing resource,也需要designer resource。投入了眾多的工程師心力,仍然在原地踏步。

德國哲學家黑格爾曾說,「人類從歷史中學到的唯一教訓,就是人類無法從歷史中吸取任何教訓。」

Delete

有個心理學效應叫「Subtraction Neglect」,它的意思是說,人們要改進某事物時,會傾向透過『添加』,而不是透過『簡化』。我們一直覺得只有不斷地添加check list,才能強化design quality。其實我們沒有想過,會不會就是我們的check list太多了,導致我們就只知道做check list上面的事,而失去獨立思考的能力。

有句話叫「Less is More.」,為什麼「少即是多」?因為Check less and think more.,唯有揭開事物的表相,窺見其中的內涵,思考問題的實相,才能知道真正的問題所在。舉例來說,當程式碼裡面有stupid bug的時候,傳統上我們就會在test pattern裡面加入各式各樣的檢查,但其實我們根本加不完所有的測試環境。也許真正的解法是我們在程式碼編寫時就要有紀律,例如採用匈牙利命名法之類的。

然而往往我們做不到整個底層的大改動,畢竟legacy code實在是太多了,於是最後便只能補丁地加check list。如果真的檢討起來,其實很多check list都是多餘的。

在工作上如此,在生活上亦然。日本人有一個觀念叫「斷捨離」,我們應當要清空不必要的物品,思考真正重要的,只保留那些有價值的物品。

回到黑格爾的話,其實他的德文原文並不是人類無法吸取教訓,而是「daß die Geschichte die Eigenheit hat, repetiert zu werden, so lange, bis die Lektion begriffen wird.」(That history has the property of being repeated until the lesson is understood.)中文意思是「歷史具有不斷重演的特性,直到教訓被人領悟為止。」

當張三接錯一條線,他知道這個錯誤的內涵,也發展出一套check list來防範再接錯這條線,的確張三就不會再犯同樣的錯了。然而李四用一樣的check list,卻仍然會接錯另外一條線,這是因為李四只知道check list的表徵,而沒有學習到錯誤的本質。

老闆總是問,不是已經有張三的check list了,為什麼還是一直有人接錯線,這次是李四、下次是王五?其實黑格爾已經回答過這問題了,因為上次學會教訓的是張三,而不是李四與王五,人們只有在出包中才會成長