Another metric besides LOC

Another metric besides LOC

Posted Jun 5, 2011 3:12 UTC (Sun) by pr1268 (subscriber, #24648)
In reply to: Another metric besides LOC by dlang
Parent article: How much GNU is there in GNU/Linux?

I'm not totally against using LOC as a metric, but it does seem to lend itself to abuse (see Tchernobog's comment above). The size of compressed source tarballs could be equally abused (consider if I threw in a 1 MB random bits file in my source tarball—that would certainly enlarge my contribution).

I'm unsure what else to use. I admit that this is a lame answer, but it's just that the stories of abusing LOC metrics permeate folklore far beyond the link in Tchernobog's comment.

I suppose a better way of measuring software code would be based on features added, tested, and verified to the code base (for new development), or defects fixed and verified (for maintenance). If an individual were to have an unusually low number of features added/defects fixed, then this could be investigated—perhaps it's not attributable to the individual being lazy or incompetent but rather the particular code is hairy. Conversely, if some "hot shot" adds a hundred features/fixes, then this too might be attributed to a bunch of simple additions/modifications, like cosmetic fixes or single-line updates (The Dilbert example I linked notwithstanding).

Please understand that I do not wish to preach management style/technique. Besides, I'm not currently in a managerial position, nor do I consider myself prepared for such a role. I'm just suggesting intuitively what might be better than LOC for software metrics.

P.S. To answer the question asked by the title of this article, I suppose that there really isn't a better way to determine how much GNU in GNU/Linux other than LOC. Sigh.

---

(Log in to post comments)