喲哪桑學長最近寫了一個有趣的故事，並在故事的後面問讀者「Feature Request, Or Bug Fixing?」這個故事引發了許多人進行廣泛的討論。
有人站在專案經理的角度來與故事中的 M 持相同的看法，只要加強 Error handling 改掉 bug 就夠了，不需要再多花工夫來回應 feature reguest。但也有人站在工程師的角度主張支持故事中 Q 的想法，解決問題本來就是 bug fixing，而修改問題所採用的做法只是 work around，而不是故事中 M 所說的這是 feature request。
不過同人覺得這個開放式的案例討論最有趣的部分，倒不是誰的看法才是正確的討論，而是看到 scarfman 「開版圖就已經說明了，bug 穿上衣服就變成 feature 啦！」的回答，這促使同人進一步地思考到一個新觀點；也就是軟體缺陷的信用創造。
如果讓 bug 穿上衣服就變成了 feature，那麼我們就可以讓穿上 feature 衣服的 bug，讓人不會感到那麼難以忍受。但如果在未來，我們又發現又出現了一個新的讓人難以忍受的問題時，我們是不是再讓它套上一件新衣服來降低人們不快的感受，以解決問題呢？
但後來沒想要最後在這個解決方案所產生的新問題，卻間接害死大樓的房東先生，使他意外喪生。最後才由電梯維修人員才發現電梯變慢的原因並加以解決（故事很精采喲，沒看過的強烈建議你去看）。
實際的軟體開發好像也跟那個大樓電梯的故事一樣，「當程式出現功能失常的時候，想辦法避開它就行了嘛，不用浪費時間對不重要的 legacy bug 增加 feature」或許就因為這種心態，讓軟體的缺陷不斷地四處擴散，使得 bug 好像沒有改完的一天。甚至發生了「總是要到驗收前，才發現程式有問題？」這類的悲慘事件。
正巧同人最近看了石頭成最近寫的文章，提到衍生性金融商品「信用創造」的古老詞彙，我發現軟體開發與財務金融雖然領域不同，但以金融的信用創造相同的觀念似乎可以用來解釋軟體缺陷的信心崩潰。畢竟經濟學是用來解釋社會現象，而軟體專案開發其實並不脫離經濟學可以解釋的範疇。
從石頭成引用的文獻資料可以理解，商業銀行的所謂「信用創造」之所以可能，只是因為短期信用的流通等於貨幣的流通。因此，創造信用就是創造貨幣。而石頭成還提到信用生產結構的迂迴，使得任一信用商品的崩潰，會延遲反饋。
用同樣的邏輯來看，專案經理利用軟體缺陷的創造信用來進行短期信用的流通，把 bug fixing 變成 feature request 的好處就等同於創造軟體缺陷貨幣的流通。然而，把 feature request 變成信用商品的後遺症，正是讓信用生產結構的迂迴，使信用崩潰延遲發生。所以我們在即將驗收時才發現 bug 改不完，其實是一種信心崩潰的必然結果。
就像學長文章那位與故事中專案經理 M 持相同看法朋友的觀點會認為，bug 是一定要改的，否則就會變成了父債子還。這樣看起來，似乎由專案上階段所遺留下來的 legacy bug 都不是 bug，而是 feature request。
但我們卻會在實際的專案中看到「債留子孫」的事實；我們只要問一問那些實際動手改 bug 的工程師，「bug 為什麼愈改愈多？」就知道，工程師實際上擔負了龐大的軟體缺陷債務，這些都是因為由前人不斷累積而來。
這些債務是如何累積來的呢？在 bug 實在太多的情形下，專案經理沒有足夠的資源與時間可以達到目標。但自認聰明的專案經理想到了一個辦法，只要讓那些 bug 穿上 feature request 的衣服，就可以帶給客戶一個美麗的遠景。使他們允許團隊向專案下一階段借貸時間與資源，並達到讓專案先行驗收的目的。
換句話說，feature request 意味著一種信用創造，可以增加軟體缺陷貨幣的流通，也就是增加了專案團隊的流動負債，以用來支應即將到期的信用負債。
顯然這將會讓專案團隊陷入了以短支長的窘境，而且對軟體缺陷，沒有「早期發現，早期治療」的結果，是必須付出龐大的代價。
例如工程師在眼前問題緊迫的情況下，選擇自廢武功，因而降低軟體的結構性使得 bug 愈改愈多，更不用說工程師的士氣與能力的低落了。等到工程師負擔不起龐大的 bug 負債時，信心崩潰就出現了，這時乙方認定的 feature request 就不會再被甲方所信任而接受了，就正如同人在〈專案不確定感的焦慮與迷思〉所舉出的真實案例。
學長這篇故事寫得真是棒呀，雖然在他的文章開頭一再地宣稱「保證絕無添加任何教育意義之成份」，但我倒是覺得是一篇文字淺顯易懂又寓有深意的文章，值得讓我在此推薦，供大家細細品味與欣賞。
