好的Source version control真的很重要，用到很鳥的（例如perforce）生命就是會浪費。
Maven 沒有incremental build實在很麻煩，有很多plugin應該要考慮把處理過程的中繼資料存起來，有改的才跑就好。
不跑integration test是省掉了一些時間沒錯，但專案一大每次重頭build還是等的很煩。
Jenkins是好東西。
GWT build 實在是浪費時間。
開發團隊一大，CI + DEV ENV就需要專人維護，而且這人還必須有經驗不能亂找，因為這人對環境的任何改進，都會直接乘到團隊的人數上。
測試真是門藝術，有些程式碼是照規矩寫，簡單檢查一遍邊界條件與異常狀況就收工了，有些測試程式碼甚至只有被執行一次的的價值。但常常一個系統最有價值的部分：扯上語言、扯上條件組合、扯上時間的，就很容易怎麼測都不是很敢保證東西在任何的合理輸入下都會對。這需要修行與案例討論。
User 方的品味與專注程度會根本性的決定成果的價值。
Code review很重要，review的人必須專心在模型可能的瑕疵與合理性上，被review的人則要對「如何有效的讓設計能被他人理解」負責...這實在超難，畢竟英文非母語，而到底是review的人心中有成見，還是被review的設計真的不夠好，這有時實在很難釐清。但被review的人是有責任去盡可能的把可以預先想到的其他設計分枝，在初始階段就先考慮過一遍的。畢竟從多個可能性裡選一個，跟一開始直覺想到的第一個就一路做下去，這絕對差很多。
跑Scrum 還是要大家都在同一間辦公室比較好，分成兩個地方實在打很多折扣。
Pair programming 是任何團隊開發絕對要優先考慮的方式，光是「兩個人一起做，所有的社交軟體的干擾就會消失掉」這點在現代就起碼給你增加了15%up的產出，其它像是知識分享，工作進程的人腦備援，旁觀者清，聚焦集中且有效率的時間區段延長等等。更重要的是透過這種方式才能逐漸瞭解其他人的思維模式，進而找出適當的分工方法。
