I reported to a manager that attempted to measure our productivity fixing bugs by comparing the lines of code before and after the fix. Most fixes reduced the lines of code, so our numbers were usually either negative or close to zero. A couple weeks later the manager interrogated the team as to why we were so unproductive.
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.
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.
Too bad that it doesn't seem like Microsoft applied that philosophy to most of its products (at least not back when I used their products. Maybe they've started recently -- I've stopped following them a few years ago when I bought a Mac).
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.
Apart from computers getting faster, Microsoft, Adobe and others should also keep up the artificial trade adequacy. If 20 years ago you'd gladly pay $400 for a software package that arrives on 20 floppy disks, the same amount today should be payed for a couple of DVD's to get the same level of emotional satisfaction. $400 for a 30-second download would be perceived as highly inadequate today, unfortunately.
"Never attribute to malice that which can be adequately explained by stupidity" - it's more likely that Microsoft's PMs and developers felt swayed by new features and possibilities and when the issue of performance came up, it was "meh, the average computer selling today can cope with it" and therefore little thought was given to performance on older tech or tech that has most of its performance diverted to other tasks.
Indeed, it could be that. But I'm still wondering if maybe it was more deliberate than that. After all, it would have been a way to make more money for both Microsoft and Intel, so there was an incentive there. And the downside was very small (what was the average Windows user going to switch to between 1995 and 2005?)
I am thinking that this comment came about in the era of the OS/2 Microsoft-IBM project. It was clear that IBM had a culture of kloc being a positive metric, and Microsoft did not.
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 scholar seeketh daily increase of knowing; the sage of Tao daily decrease of doing. He decreaseth it, again and again, until he doth no act with the lust of result. Having attained this Inertia all accomplisheth itself. He who attracteth to himself all that is under Heaven doth so without effort. He who maketh effort is not able to attract it." - Tao Teh King, Chapter XLVIII (Crowley's translation)
I love the feeling after having rewritten some code part with the results of having it much shorter, much clearer, more stable and even faster. :) In almost all cases, it was worth it.
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? :)
All code can be made shorter. But all code also has at least one bug. So eventually your code will be just one byte - but it will be the wrong byte :-)
If you look at programming as a knowledge acquisition activity instead of a code production activity, then you couldn't possibly have implemented it that way in the first place.
Exactly. Usually I don't have (or give myself) the luxury, but when I'm working on something small and I don't really have time constraints for it, I will write it, then rewrite it, then look at it from a different angle, and rewrite it again. Only after about three rewrites will I get something that looks good.
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.
This was pure joy to read. Management asks for something foolish and counterproductive, and then one of the top techs pushes the absurdity right back in their faces -- take this: obvious big win, but a drastic opposite delta by your crude, misguided, metric!
My kids stared at me laughing very loudly for quite a few seconds :-)
I've seen this great folklore story hit the front page of HN more than a few times, but it is worth it every time. It is a good reminder for every programmer that verbose, complex solutions aren't necessarily good ones.
This is one of those posts that periodically appears, but something that's almost never pointed out is that QuickDraw was written in assembly. So, by reducing the lines of code, not only did he reduce the complexity but he also directly made the code faster by being smaller.
Everybody here is having a great time beating this mostly-dead horse, but I know for a fact that I have more productive weeks and less productive weeks, and in those less productive weeks I usually write way less LOC.
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...").
It's not infinite. It's equivalent to while(i<count). The right side of the && has no effect (for i<count, !(i>count) is always true, and it short circuits to false when i==count).
"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte." - Blaise Pascal = "I would have written a shorter letter, but I did not have the time."
Counting the number of lines must be done after the algorithm is described. There are two roles: those finding the correct algorithm for a problem and those writing the code for implementing the algorithm.
I reported to a manager that attempted to measure our productivity fixing bugs by comparing the lines of code before and after the fix. Most fixes reduced the lines of code, so our numbers were usually either negative or close to zero. A couple weeks later the manager interrogated the team as to why we were so unproductive.
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.
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.
Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates
I never saw this quote in the past, but apparently it's quoted a lot. And it's so true.
Too bad that it doesn't seem like Microsoft applied that philosophy to most of its products (at least not back when I used their products. Maybe they've started recently -- I've stopped following them a few years ago when I bought a Mac).
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.
Apart from computers getting faster, Microsoft, Adobe and others should also keep up the artificial trade adequacy. If 20 years ago you'd gladly pay $400 for a software package that arrives on 20 floppy disks, the same amount today should be payed for a couple of DVD's to get the same level of emotional satisfaction. $400 for a 30-second download would be perceived as highly inadequate today, unfortunately.
"Never attribute to malice that which can be adequately explained by stupidity" - it's more likely that Microsoft's PMs and developers felt swayed by new features and possibilities and when the issue of performance came up, it was "meh, the average computer selling today can cope with it" and therefore little thought was given to performance on older tech or tech that has most of its performance diverted to other tasks.
Indeed, it could be that. But I'm still wondering if maybe it was more deliberate than that. After all, it would have been a way to make more money for both Microsoft and Intel, so there was an incentive there. And the downside was very small (what was the average Windows user going to switch to between 1995 and 2005?)
Ha! You might as well say Linus Torvalds was in the conspiracy too, since Linux required a 386 when the 286 was more common!
I am thinking that this comment came about in the era of the OS/2 Microsoft-IBM project. It was clear that IBM had a culture of kloc being a positive metric, and Microsoft did not.
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%.
Since this is turning into a quote thread, I'll throw another one in:
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
Well, if we're really doing this...
"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.
"The scholar seeketh daily increase of knowing; the sage of Tao daily decrease of doing. He decreaseth it, again and again, until he doth no act with the lust of result. Having attained this Inertia all accomplisheth itself. He who attracteth to himself all that is under Heaven doth so without effort. He who maketh effort is not able to attract it." - Tao Teh King, Chapter XLVIII (Crowley's translation)
“If we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent'" - Edsger Dijkstra
I love the feeling after having rewritten some code part with the results of having it much shorter, much clearer, more stable and even faster. :) In almost all cases, it was worth it.
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? :)
All code can be made shorter. But all code also has at least one bug. So eventually your code will be just one byte - but it will be the wrong byte :-)
If you look at programming as a knowledge acquisition activity instead of a code production activity, then you couldn't possibly have implemented it that way in the first place.
Exactly. Usually I don't have (or give myself) the luxury, but when I'm working on something small and I don't really have time constraints for it, I will write it, then rewrite it, then look at it from a different angle, and rewrite it again. Only after about three rewrites will I get something that looks good.
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.
The only thing better than writing code is deleting it.
Amen.
Code is the enemy. Code is weak. Code breaks. Coding is a last resort.
A gear never breaks after it has been designed out of the machine.
But electronics just rot on the shelf, too.
This was pure joy to read. Management asks for something foolish and counterproductive, and then one of the top techs pushes the absurdity right back in their faces -- take this: obvious big win, but a drastic opposite delta by your crude, misguided, metric!
My kids stared at me laughing very loudly for quite a few seconds :-)
It's not that funny...
It was if this is the first time you'd come across the concept. :D
I've seen this great folklore story hit the front page of HN more than a few times, but it is worth it every time. It is a good reminder for every programmer that verbose, complex solutions aren't necessarily good ones.
This is one of those posts that periodically appears, but something that's almost never pointed out is that QuickDraw was written in assembly. So, by reducing the lines of code, not only did he reduce the complexity but he also directly made the code faster by being smaller.
>he also directly made the code faster by being smaller.
Only if you assume that there are no jumps (loops) in that code.
Everybody here is having a great time beating this mostly-dead horse, but I know for a fact that I have more productive weeks and less productive weeks, and in those less productive weeks I usually write way less LOC.
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.
Simplicity is harder to achieve than complexity. Try to solve problems by removing things, not adding them.
The key to performance is elegance, not battalions of special cases - Alan Kay
Google Cache[1].
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...").
[1]: http://webcache.googleusercontent.com/search?sourceid=chrome...
There's this one: http://thedailywtf.com/Articles/Productivity-20.aspx
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.
Only wusses need comments in order to bloat their code. There are so many "effective" alternatives.
Oh yes, if I had it my way we'd all write for loops like so:
infinite loops?
nothing infinite here.
No increment is specified.
Sure, but that goes either way and there is no tautology.
It's not infinite. It's equivalent to while(i<count). The right side of the && has no effect (for i<count, !(i>count) is always true, and it short circuits to false when i==count).
i don't see anything that increments 'i'
That would be because you don't see the body of the loop.
I did miss that out accidentally but I'm sticking like glue to your reason.
If you want to count lines of C you count semicolons.
Measuring lines of code is valid. The only caveat is that you must be intimately aware of whose lines of code you are counting.
Here's a previous submission of this item, along with its attendant discussion:
http://news.ycombinator.com/item?id=1114223
Not productive enough ;) "One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson
"Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le loisir de la faire plus courte." - Blaise Pascal = "I would have written a shorter letter, but I did not have the time."
Counting the number of lines must be done after the algorithm is described. There are two roles: those finding the correct algorithm for a problem and those writing the code for implementing the algorithm.