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個又為什么不是BUG？BUG的評價標準難道是程序員說了算？這個環節管理缺失。
4、5個不能工作的BUG修改問題有沒有追究責任？增加新BUG是修改過程中不可避免的事情，但是如果有有效的單元測試機制，可以大大減少這種情況。這個環節管理缺失。
5、迭代是正常的，但是問題處理于發散而不是收斂發展，可見沒有有效的管理調控。這個環節管理缺失。
6、過于樂觀的時間表和不可能達到的最后期限，都表現出管理者的無知和無能。而在這樣的情況下強行推出產品，那就是無知者無畏了。
7、這是對用戶的不負責任，管理者要負最大的責任。
8、這樣的情況還能發項目獎金，只能說管理者不是一般的愚蠢。
9、管理工作沒有任何的改進，問題仍然處于發散迭代狀態。管理工作依然沒有到位。
10、拖欠測試部門工資體現出管理者對質量管理工作的忽視以及對人力資源管理方面一無所知。
11、送被收購者兩個字：活該。送收購者兩個字：瞎眼。
12、可見新管理者與原管理者半斤八兩，都沒有認識到問題的根本所在。不過也只有這樣的管理者才會作出收購這種公司的決策。
13、歷史的重演是必然的。
一個正常的企業或是項目，其運作必須應該是循環向上進行的。而保障這種運行的工作就是管理。而管理工作的主要內容就是控制，包括控制循環的節奏——不能太快也不能太慢，控制發展的方向——只能向上不能向下，控制運作的穩定——不能大起大落或時聚時散等。
而這一切，在這個例子中都看不到。
在這個笑話的例子中，一切都是以開發工作在驅動，這首先就是一個方向性錯誤，產品是為用戶服務的，當然應該是以用戶和市場作為驅動，并且結合自身的能力最終 確定工作的重點。這一錯誤折射出管理者對被管理的內容很不了解，只好任由比較了解的程序員擺布——事實上他們除了技術，并不會了解更多。
一個管理者如果對自己所管理的內容不了解，他就不可能管理得好。
這是一件毫無疑問的事，可是國內的軟件業似乎總是不相信這一點。中國軟件業中流毒最深的謊言之一就是：
管理者只要懂管理就可以，不需要懂技術。
其實這不過是那些無知無能無恥的管理者為了騙錢而編出來的，相信這句話的人必將付出金錢的代價。
其次是質量管理。基本的質量管理常識告訴我們，每次循環結束前，最重的工作就是總結改進。只有這樣才能保證循環運作是向上發展，而不是失去控制地向下發展。 也只有有效的質量管理，才能保證迭代過程是收斂發展，并最終達到目標。但在這個例子中，這個部分顯然是缺失的——其中雖然有測試部門，但是他們的作用僅僅 是質量管理中的質量檢測環節，管理部分還是缺失的。
然后是人力資源管理。軟件開發是一項勞動密集型的工作，雖然這是腦力勞動，但同樣意味著人在因素在其中占有決定性的地位。而例子中未改完BUG的程 序員拿到項目獎金，而同樣辛苦工作的測試人員卻被拖欠薪資，除了表現出管理者對他們的工作內容的不了解，以及對質量管理工作的不重視以外，還表現出管理者 完全不會管人，這是一種謀殺團隊的行為——謀殺一個團隊遠比建設要容易得多。
最后，這個失敗的管理者把他的經歷編成這個笑話，讓大家看到他被程序員們害得多慘，把程序員妖魔化為一群騙子。但只要稍懂管理的人簡單分析一下就可以看出來，只不過是這個人的無知和無能造成了他現在的結果，而把責任推給別人的行為更是表現出他的無恥。
作為身居高位的管理者，如果連應該承擔的責任都要推卸，他們還能勝任什么事情呢?