Another fun experiment is to measure developers using lines of code, and then switch to unit test coverage. For some reason, the code always seems to shrink.
Counting lines of code for maintenance work is a little like evaluating your mechanic based on the weight difference of your car before and after he fixes it.
I love this comment.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
"It's not the daily increase but the daily decrease. Hack away at the unessential." - Bruce Lee
Obviously not hack as in hack, but when it came to fighting he was a better hacker than any of us.
I wonder if any ex-Microsoft employee ever came out and said that they actually had the explicit goal of making each successive version of their main products (windows, office) much slower than the last so that people would upgrade to a new computer, making Intel happy, and leading to more "comes with the computer" licenses instead of pirating.
I think it is useful to keep in mind that gobs of features sell, and (was it Joel Spolskey?) someone noted that any given user needs only 11% of a product such as a word processor, but another user needs a different 13%.
The strange thing is, sometimes there are multiple iterations of this on the same code part (sometimes by different people, sometimes even by my own).
Then I am thinking, maybe I just have gotten wiser, have learned my lesson or whatever. Stupid me that I haven't implemented it in the first place like this.
Also, I am always wondering, how much more iterations are there until I get to some final, perfect, optimal solution.
Or will I really end up with one single line of code in the end? :)
I'd like to bring this down to writing something good looking earlier, but it's like you say - I only learned it then and there.
My kids stared at me laughing very loudly for quite a few seconds :-)
Only if you assume that there are no jumps (loops) in that code.
What's more, if you just slightly adjust this metric to "patch size", as in count lines added as well as lines removed, you'll get a more accurate measure, and also make the linked story moot.
Measuring developer progress is incredibly hard, but we have to do it anyway, and "use your gut" cannot be the only advice on this. At the very least, comparing this metric for the same person over different periods of time can give you a clue as to how they're doing.
Reminds me of that TDWTF post where engineers were paid based on the amount of lines of code they had written - led to massive comment blocks explaining the simplest things ("This is a for loop that works by...").
where a guy boosts his line count by writing a program convert loops into goto spaghetti (pretty much like the generated assembly, right?).
But has anyone here actually been evaluated in this way? I've never heard about it first hand - it almost seems like an urban legend.
int i = 0;
int count = 20;
(i < count)
!(i > count)
// some code