我 2008年在清華大學上<現代軟件工程> 的時候,  和同學討論了代碼量的問題。 同學說，許多相似課程都有“代碼量”的要求，就是說軟件工程的項目選題如果沒有到一定量的代碼，就不能算合格的選題。  老師助教專門花時間分析學生的代碼是否夠 “量”。 我對教學沒什么經驗，我認為 -

軟件工程課上寫的軟件只要解決實際問題，就至少是及格的選題。

我后來順口胡謅了一段：

清華園有兩棵果樹，春天長芽，抽條，夏天開花，秋天結果。清華軟件科學試驗班的同學去采摘，發現果樹A 的果實比果樹B 的果實多很多，并且好吃。于是同學們都在果樹A上采摘，并在果樹A下面合影留念。 果樹B 很委屈，它在秋風中搖晃樹葉, 說 – 可是我的樹葉量是它的三倍！清華的同學沒聽懂果樹B 在颯颯秋風中的抱怨，背著果實走了。 冬天來了，樹葉落了一地，同學們又來打掃果園，一個同學說，我k！這棵樹怎么這么多葉子！

代碼量等于樹葉量，當作如是觀。 

測試人員的 "量" 如何度量和評價呢?  能否用發現的 bug  的數量來看?  我在 <移山之道> 里寫了一個故事,  專家也有很多論述, 例如:

http://www.kaner.com/pdfs/bugcount.pdf  

I don’t have a silver bullet for personnel measurement. When I compare the quality of testers, I spend a lot of time looking at the quality of their work. I read bug reports. I
talk with them. I talk with people that they work with. I pay attention to promises they make, and whether they keep them. These don’t lend themselves to quick and easy number crunching, although you can (perhaps with difficulty) do comparative ranking of testers based on this detailed qualitative look.
If you really need a simple number to use to rank your testers, use a random number generator. It is fairer than bug counting, it probably creates less political infighting,
and it might be more accurate. 

很多開發人員還以自己寫了多少代碼為驕傲，枝葉繁茂, 是不錯, 但是這些代碼是否能有機地結合起來, 解決客戶的問題?

項目開發中后期，Dev lead用工具一統計，乖乖，足足xx萬行代碼，xx千個存儲過程，可是每到給客戶演示時，卻不時出現程序的各個功能相互不配合，不能自圓其說的尷尬場景，Dev lead很郁悶，想想自己可是沒少加班啊，代碼量也有，可是問題究竟出在什么方面呢？

<回答在這里>