“現在，程序設計工作已經成了試圖創建更大更好的傻瓜式程序的軟件工程師和試圖製造更大更高的傻瓜的上天之間的較量。迄今為止，上天贏了。”這話是技術商業作家Rick Cook說的。什麼意思？往下看就明白了。
盡管我把軟件工程師當作偶像，但他們仍然頻繁地撒謊。也許撒謊是創新所必須的，太多人會告訴你，你想做的東西無法達成或者根本沒人想要。隻要知道他們在撒謊，你就不用擔心。下麵是一些工程師經常說的謊言。
1 “我對市場一無所知”。這是一句假的謙遜之辭。事實上，這位工程師正在想的是，“我不了解市場營銷，但與我所做的工作相比，那又算得了什麼？工程和市場我都能應付自如，我隻是希望那些MBA能夠提出一些配得上我寫出的代碼的想法”。不過，不用對此太擔心，在工程師錯過了一個個產品開發的最終截止日期之後，他們會發現自己遇到了麻煩。
2 “我們將要進行測試”。這是一個毫無意義的陳述，因為關鍵不在於什麼時候開始測試，而在於什麼時候完成測試。目前看來，惟一能夠肯定的測試完成日期，就是錢花光的時候。
在過去，產品Alpha版本的意思是“所有的部分都完成了，盡管不一定能夠合格運作”；Beta版本的意思是，“不會再出現重複性的錯誤了”。而到了現在，Beta版本則意味著，“在承諾的交貨期之後，我們就消失了”。
3 “我已經對代碼進行了注釋，後來者可以看懂我的工作”。工程師確實打算對代碼進行注釋，不過隨著日子漸漸過去，工作重點也發生了變化。管理層將麵對這樣的問題：“你是想讓我為代碼進行注釋還是盡快完成項目”？答案不言而喻。幸運的是，缺少注釋並沒有什麼關係，因為代碼是如此蹩腳，一年之內肯定需要重新編寫。
4 “我們的產品結構是可擴展的”。這是我最樂於聽到的謊言。一般來說，從未交付過產品的工程師在vB中建立模型後會這麼說。整個謊言是這樣的：“Google的擴展性不如我們。他們可以支持2，500萬次同時搜索，而我們可以輕而易舉地處理10億次。”幸運的是，在大多數情況下，產品真正能夠應用所花的時間要比CEO的保守估計還長，所以可擴展性從來也不是—個重要問題。
5 “我們編寫的代碼支持所有行業標準”。這幾乎是事實，當然還需要一點補充：“這些代碼支持著我所認同的所有行業標準”。工程師對他不喜歡的標準習慣地選擇視而不見——例如那些微軟頒布的標準。對工程師來說，這無關緊要，反正客戶不會知道這些。
6 “我們有一個數據庫和係統，可以有效地報告bug”。但是，故障報告係統的設計前提是係統中沒有故障，所以不需要報告。一艘情況下，如果記錄的故障從不超過1，000個，那隻能說明這個公司沒有進行仔細的檢查。