有一個笑話是這樣的：
1. 程式師寫出自認為沒有Bug的代碼。
2. 軟體測試， 發現了20個Bug。
3. 程式師修改了10個Bug， 並告訴測試組另外10個不是Bug。
4. 測試組發現其中5個改動根本無法工作， 同時又發現了15個新Bug。
5. 重複3次步驟3和步驟4。
6. 鑒於市場方面的壓力， 為了配合當初制定的過分樂觀的發佈時間表， 產品終於上市了。
7. 用戶發現了137個新Bug。
8. 已經領了專案獎金的程式師不知跑到哪裡去了。
9. 新組建的專案組修正了差不多全部137個Bug， 但又發現了456個新Bug。
10. 最初那個程式師從斐濟給飽受拖欠工資之苦的測試組寄來了一張明信片。 整個測試組集體辭職。
11. 公司被競爭對手惡意收購。 收購時， 軟體的最終版本包含783個Bug。
12. 新CEO走馬上任。 公司雇了一名新程式師重寫該軟體。
13. 程式師寫出自認為沒有Bug的代碼。
要我說， 如果真有這樣的公司， 不倒閉對不起人民。
這個笑話從程式師開始， 到程式師結束， 從頭到尾都在說程式師的不是。 但是我要說的是， 這完全是管理者的失敗， 從整個過程中， 看不到任何管理工作。 這種管理者不但無知無能， 還很無恥——將自己的失敗責任推給程式師。
1. 程式師憑什麼證明他的代碼沒有Bug？有Test case嗎？有Code review嗎？這個環節管理缺失。
2. 測試發現Bug有進行Bug管理嗎？有跟蹤嗎？這個環節管理缺失。
3. 憑什麼證明程式師已經把那10個Bug修改好了？另10個又為什麼不是Bgu？Bug的評價標準難道是程式師說了算？這個環節管理缺失。
4. 5個不能工作的Bug修改問題有沒有追究責任？增加新Bug是修改過程中不可避免的事情， 但是如果有有效的單元測試機制， 可以大大減少這種情況。 這個環節管理缺失。
5. 反覆運算是正常的， 但是問題處理於發散而不是收斂發展， 可見沒有有效的管理調控。 這個環節管理缺失。
6. 過於樂觀的時間表和不可能達到的最後期限， 都表現出管理者的無知和無能。 而在這樣的情況下強行推出產品， 那就是無知者無畏了。
7. 這是對用戶的不負責任， 管理者要負最大的責任。
8. 這樣的情況還能發專案獎金， 只能說管理者不是一般的愚蠢。
9. 管理工作沒有任何的改進， 問題仍然處於發散反覆運算狀態。 管理工作依然沒有到位。
10. 拖欠測試部門工資體現出管理者對品質管制工作的忽視以及對人力資源管理方面一無所知。
11. 送被收購者兩個字：活該。 送收購者兩個字：瞎眼。
12. 可見新管理者與原管理者半斤八兩， 都沒有認識到問題的根本所在。 不過也只有這樣的管理者才會作出收購這種公司的決策。
13. 歷史的重演是必然的。
一個正常的企業或是項目， 其運作必須應該是迴圈向上進行的。 而保障這種運行的工作就是管理。 而管理工作的主要內容就是控制， 包括控制迴圈的節奏——不能太快也不能太慢， 控制發展的方向——只能向上不能向下， 控制運作的穩定——不能大起大落或時聚時散等。
而這一切， 在這個例子中都看不到。
在這個笑話的例子中，
一個管理者如果對自己所管理的內容不瞭解， 他就不可能管理得好。
這是一件毫無疑問的事， 可是國內的軟體業似乎總是不相信這一點。 中國軟體業中流毒最深的謊言之一就是：管理者只要懂管理就可以， 不需要懂技術。