As an Eclipse user, you know that the new release Galileo is available. This chart represents the evolution of the Eclipse project (found here):
In 6 years, the Eclipse project counts now 33 sub-projects and 24 millions Lines Of Code (LOC). The number of projects demonstrates that its incubator is really useful but, I don’t like to see the number of lines of code. In his article “Cannot Measure Productivity“, Martin Fowler wrote:
Any good developer knows that they can code the same stuff with huge variations in lines of code, furthermore code that’s well designed and factored will be shorter because it eliminates the duplication. Copy and paste programming leads to high LOC counts and poor design because it breeds duplication. You can prove this to yourself if you go at a program with a refactoring tool that supports Inline Method. Just using that on common routines should allow you to easy double the LOC count.
You would think that lines of code are dead, but it seems that every month I see productivity studies based on lines of code – even in such respected journals as IEEE Software that should know better.
Now this doesn’t mean that LOC is a completely useless measure, it’s pretty good at suggesting the size of a system. I can be pretty confident that a 100 KLOC system is bigger than a 10KLOC system. But if I’ve written the 100KLOC system in a year, and Joe writes the same system in 10KLOC during the same time, that doesn’t make me more productive. Indeed I would conclude that our productivities are about the same but my system is much more poorly designed.
What I mean is that, for a project of the size of Eclipse, the rise of this metric doesn’t provide any information. A project with 17 MLOC is as big as a project with 24 MLOC: they are both huge projects. What would be interesting to know is whether dead code is removed between releases or whether redundant code is refactored. Ohloh can give you an idea. For sample, if we’re looking at the MySQL project, we can get this chart:
Mysql - Ohloh - LOC
The fact that the number of LOC decreases sometimes can give us an hint on the project. We can hope that it is related to refactor/clean up sessions.
In summary, the number of lines of code provides only an idea of what the size of a project is. When the project is becoming bigger and bigger and that the size never decreases, refactoring stuffs are probably never done and the cost to enter in the code increases significantly.
Measuring progress by lines of code is like measuring aircraft building progress by weight, Bill Gates
NB: I only use the Eclipse chart to discuss about this metric, I like Eclipse and I don’t deduce that Eclipse developers don’t make any refactoring: this chart is not enough.
Comments 17
Good post. Indeed, what I find more useful is a integrated set of metrics – LOCs, FindBugs, PMD, CMD reports, etc… Today’s CI servers such as Hudson are able to do pretty graphics with metrics and if you see that LOCs shrink, at the same time the number of functional tests doesn’t decrease and the CPD graph lowers, it’s a better sign of good refactoring. This is why I say that CI + proper metrics are – beyond engineering – a good tool for project management and project managers should hopefully be able to “read” their reports.
Posted 09 Sep 2009 at 12:26 pm ¶Hello Fabrizio,
Sorry for the delay of my answer.
Hudson makes pretty graphics, I agree. A combination of many metrics is really a useful information when you try to follow a project : it gives a good overview of the current status.
Do you know Sonar? http://sonar.codehaus.org/
This project tries to give a global report from some metrics.
Thank you for your comment.
Posted 15 Sep 2009 at 8:19 pm ¶Coderfriendly
Yes, I know it and I’ve a low-priority plan to install it – it can be used with a Hudson plugin. The priority is low because I’ve got other tons of things to do, indeed Sonar look really useful.
Posted 15 Sep 2009 at 8:36 pm ¶“Other tons of things to do”… It is our common problem, it’s the same for me
.
Posted 15 Sep 2009 at 9:29 pm ¶Obvious article is obvious.
This comment was originally posted on Reddit
Posted 08 Dec 2009 at 12:45 am ¶Hi, I’m french so I don’t know really how to understand "obvious" there. Does it mean that you didn’t like it? Bye
This comment was originally posted on Reddit
Posted 08 Dec 2009 at 9:16 pm ¶Hm, this is going to be difficult to explain… "Obvious article is obvious" isn’t a correct sentence. It’s a meme from somewhere on the internet, probably 4chan. It means that what the article says is obvious. "Obvious" means that it is so clear that it doesn’t need to be said. You don’t go around writing about how the sky is blue, do you? That’s because it’s *obvious* that the sky is blue. Everybody knows it.
This comment was originally posted on Reddit
Posted 08 Dec 2009 at 9:50 pm ¶Okay, I understand your view, it’s what I have understood from your previous comment. I thought it was obvious too, but the question is coming again and again. I can just make a citation from the excellent article from Martin Fowler, CannotMeasureProductivity… "You would think that lines of code are dead, but it seems that every month I see productivity studies based on lines of code – even in such respected journals as IEEE Software that should know better.", Martin Fowler. So, yes, for many programmers, it’s obvious, but it is not an universal view. Thank you for your comment.
This comment was originally posted on Reddit
Posted 08 Dec 2009 at 9:56 pm ¶pretty glad you were forced to explain your stupid meme post here
This comment was originally posted on Reddit
Posted 08 Dec 2009 at 11:50 pm ¶The objective of a blog is to get feedback on our writing. You think this post is stupid, it’s your opinion, but it’s not mine.
This comment was originally posted on Reddit
Posted 09 Dec 2009 at 12:17 am ¶a meme is, by definition, stupid – a parroting of a line with no underlying thought
This comment was originally posted on Reddit
Posted 09 Dec 2009 at 12:22 am ¶I don’t think you actually know what a meme is. "Meme" isn’t just an internet word. Your own use of the word "parroting" is a meme; do you honestly think you’re the first person to think of comparing a person who repeats the words of others to a parrot? In this case, the underlying thought was, "This is obvious, why write about it?" Do you disagree?
This comment was originally posted on Reddit
Posted 09 Dec 2009 at 12:38 am ¶why didn’t you just write that instead
This comment was originally posted on Reddit
Posted 09 Dec 2009 at 12:53 am ¶I actually disagree with the article. Lines of code are useless when measured for different projects or developers, or languages. But continuing work on the same project in the same language and by the same developers does tend to make it better: new features are added, more edge cases or error conditions are handled, and existing code might be optimised further.
This comment was originally posted on Reddit
Posted 09 Dec 2009 at 3:48 am ¶> But continuing work on the same project in the same language and by the same developers does tend to make it better: new features are added, more edge cases, platform or hardware peculiarities or error conditions are handled, and existing code might be optimised further. True, but I don’t see how that’s related to lines of code. These kinds of changes reduce the number of lines almost as often as they increase them.
This comment was originally posted on Reddit
Posted 09 Dec 2009 at 4:06 am ¶Because some people find those memes humorous. Obviously you aren’t one of those people.
This comment was originally posted on Reddit
Posted 09 Dec 2009 at 4:09 am ¶Exactly, refactoring is an important step that is so often forgotten. The fact is that, in our world, we want to get metrics to say that we’re moving forward: lines of code alone is a bad one. If you combine this metric with other ones (test coverage, bugs fixed, user satisfaction, static code analysis, …), you probably get a better idea of the status of your project. LOC metric alone doesn’t mean anything!
This comment was originally posted on Reddit
Posted 09 Dec 2009 at 7:53 pm ¶Post a Comment