Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
John Chambers <jc at trillian.mit.edu> wrote: >Au contraire, this is about the worst possible basis for >rewarding the programmers. It is incredibly easy to pad >code to produce a large line count. While certainly not open source, when at Raytheon this past year, I had to estimate the number of lines in the HP-UX driver I was writing because all the code metrics on the project were based on number of lines of code (this was mandated not by Raytheon, but by the prime contractor, and probably by the Army in this case). I do agree completely with John Chambers that measuring the number of lines of code is a very poor way to measure programmer productivity. Over the years there have been many attempts to try to quantify productivity. If programmers were paid based on the number of lines of code, we would all be writing COBOL, which is an incredibly verbose language. In contrast, APL is a language used primarily by mathemeticians (although I have seen it used for corporate budgets, spread sheets, and even a corporate inventory system). APL is a very compact language which uses virtually every character in the greek alphabet. It's been 20 years since I did any work with APL, but a single line (under 80 characters) of APL can be the equivalent of hundreds of lines of some other languages. -- Jerry Feldman Contractor, eInfrastructure Partner Engineering 508-467-4315 http://www.testdrive.compaq.com/linux/ Compaq Computer Corp. 200 Forest Street MRO1-3/F1 Marlboro, Ma. 01752 - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |