「就像寫程式一樣，剛剛寫的時候是覺得新奇有趣的。但當程式寫好，專案結束的時候，就算一開始時是多麼新奇有趣，也不想再開來看。我的缺點就是這樣......」雖然這是改編自某電視劇主角的對白(當時正用來游說另一位女朋友結束其關係)，但這是我們這些經驗尚淺的Programmer都認同的。為了趕及限期，程式碼寫得亂七八糟也不要緊，反正可以做到要求便可以了。不過，相隔一段時間後，如果有人對你曾經做過的專案感興趣，想你為這個程式增加或改良一些功能，就算有人給你一個高價，也不會心甘情願去做。因為你的程式碼就如給加密了一樣，只有你自己才可以看明白，但是現在你連當時的「解密匙」也忘掉了，就更加不想再打開程式碼來看。
不想你的專案絕子絕孫，你的專案一定要有文件說明，你既然知道要寫說明書給用戶，用戶才會懂得使用，為何你會以為不寫說明書給程式員，程式員會懂得如何把程式發展下去呢?為專案寫一份詳細的文件，記載你的軟體如何設計，程式碼是如何安排。讓後人得知你的軟體如何持續發展，你的軟體才會兒孫滿堂，而你也可安享晚年吧。
各位，又來到Project Work天氣報告。我和Charlie的工作進度沒有受老師的影響，平穏發展。一起看看天氣圖，一股CA高氣壓正逐漸逼近。預測未來的日子將會因其他科目的壓力而減慢Project work的進度，所以再有進步的空間已經不大。因此如果想做一些很大型的functions，現在為時已晚了。現在要做的是一些穩重的function，即是做了便一定會用到的。做滿80-90%便要去做其他低於這個數字的function了。
好了，廢話說完了，現在報告中期進度了，David的總進度是53%，合格機會屬於高。而Charlie的總進度是63%;合格機會屬於極高;Fai的總進度是35%，合格機會屬於低。對於合格機會不是極高的組員，可以說的是：「除了要花更多時間在Project Work外，還要花更多時間找出User的真正需要，請參考專案時間不足，如何達成不可能的任務一文。花最多時間做的人未必是做得最好的，最重要的在於所花的地方是否最有價值。」要化腐朽為神奇，一定要試試，否則...神仙難救了。記住，不要做太陽能電筒呀!
| Tasks | Exact Progress | Expected Progress | Difference |
| Maintain Reminder | 85% | 100% | -15% |
| Generate Gantt Chart | 100% | 100% | 0% |
| Find Out Workload | 25% | 100% | -75% |
| Produce Project Progress Report | 0% | 30% | -30% |
| Maintain Data | 85% | 100% | -15% |
| Generate PERT Chart | 90% | 100% | -10% |
| Generate Timetable | 15% | 100% | -85% |
| Monitor Project | 0% | 75% | -75% |
| Produce Project Analyze Report | 40% | 100% | -60% |
| Produce Staff Analyze Report | 50% | 100% | -50% |
| Produce Cost Report | 50% | 100% | -50% |
| Average Progress | 49% | 20% | 29% |
| Expected Progress | 85% | -85% | |
| Max Speed | 6% | -6% | |
| Progress Group David | 53% | 83% | -30% |
| Progress Group Charlie | 63% | 94% | -30% |
| Progress Group Fai | 35% | 80% | -45% |
AISP的Project Manger又在我們的Tools中找到bugs了。
這個bug來得偶然，不是刻意(即使是刻意找)也找不出來。所以要找這個bugs便要多試幾次了。
這個bug的重要性是2，強度屬於「低」。
請用原因說服我