8 ms·

-2000 lines of code

210 points by aycangulez 16y ago

albertzeyer 16y ago
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? :)
- sp332 16y ago
  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 :-)
- sreitshamer 16y ago
  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.
  - yesbabyyes 16y ago
    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.
RossM 16y ago
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&ie=UTF-8&q=cache:http://folklore.org/StoryView.py%3Fproject%3DMacintosh%26story%3DNegative_2000_Lines_Of_Code.txt http://webcache.googleusercontent.com/search?sourceid=chrome...
- SandB0x 16y ago
  There's this one: http://thedailywtf.com/Articles/Productivity-20.aspx 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.
- dennisgorelik 16y ago
  Only wusses need comments in order to bloat their code. There are so many "effective" alternatives.
  - RossM 16y ago
    Oh yes, if I had it my way we'd all write for loops like so: int i = 0; int count = 20; while( (i < count) && !(i > count) ) { // some code }
    - derwiki 16y ago
      infinite loops?
      - kxs 16y ago
        nothing infinite here.
mian2zi3 16y ago
The only thing better than writing code is deleting it.
- peterb 16y ago
  Amen.
aheilbut 16y ago
“If we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent'" - Edsger Dijkstra
spivey 16y ago
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.
- dhimes 16y ago
  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.
mrduncan 16y ago
Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates
- dennisgorelik 16y ago
  I never saw this quote in the past, but apparently it's quoted a lot. And it's so true.
  - MikeCapone 16y ago
    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.
    - mojuba 16y ago
      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.
    - skalpelis 16y ago
      "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.
api 16y ago
Simplicity is harder to achieve than complexity. Try to solve problems by removing things, not adding them.
- gaius 16y ago
  The key to performance is elegance, not battalions of special cases - Alan Kay
  - deleted 16y ago
    [deleted]
  - neutronbob 16y ago
    The quotation comes not from Alan Kay, but Jon Bentley and Doug McIlroy. It's discussed here with Bentley: http://www.drdobbs.com/architecture-and-design/207000707 http://www.drdobbs.com/architecture-and-design/207000707
Roboprog 16y ago
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 :-)
- Gonsalu 16y ago
  It's not that funny...
  - antipaganda 16y ago
    It was if this is the first time you'd come across the concept. :D
NathanKP 16y ago
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.
mcantor 16y ago
Code is the enemy. Code is weak. Code breaks. Coding is a last resort.
isnoteasy 16y ago
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.
jballanc 16y ago
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.
- fierarul 16y ago
  >he also directly made the code faster by being smaller. Only if you assume that there are no jumps (loops) in that code.
Eliezer 16y ago
A gear never breaks after it has been designed out of the machine.
- eru 16y ago
  But electronics just rot on the shelf, too.
exception 16y ago
Measuring lines of code is valid. The only caveat is that you must be intimately aware of whose lines of code you are counting.
itsadok 16y ago
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.
riccardom 16y ago
Not productive enough ;) "One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson
binaryfinery 16y ago
"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."
RiderOfGiraffes 16y ago
Here's a previous submission of this item, along with its attendant discussion: http://news.ycombinator.com/item?id=1114223 http://news.ycombinator.com/item?id=1114223

-2000 lines of code

210 points by aycangulez 16y ago

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? :)

sp332 16y ago
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 :-)
sreitshamer 16y ago
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.
- yesbabyyes 16y ago
  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.

RossM 16y ago

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&ie=UTF-8&q=cache:http://folklore.org/StoryView.py%3Fproject%3DMacintosh%26story%3DNegative_2000_Lines_Of_Code.txt http://webcache.googleusercontent.com/search?sourceid=chrome...

SandB0x 16y ago
There's this one: http://thedailywtf.com/Articles/Productivity-20.aspx 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.
dennisgorelik 16y ago
Only wusses need comments in order to bloat their code. There are so many "effective" alternatives.
- RossM 16y ago
  Oh yes, if I had it my way we'd all write for loops like so: int i = 0; int count = 20; while( (i < count) && !(i > count) ) { // some code }
  - derwiki 16y ago
    infinite loops?
    - kxs 16y ago
      nothing infinite here.

mian2zi3 16y ago

The only thing better than writing code is deleting it.

peterb 16y ago
Amen.

aheilbut 16y ago

“If we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent'" - Edsger Dijkstra

spivey 16y ago

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.

dhimes 16y ago
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.

mrduncan 16y ago

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates

dennisgorelik 16y ago
I never saw this quote in the past, but apparently it's quoted a lot. And it's so true.
- MikeCapone 16y ago
  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.
  - mojuba 16y ago
    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.
  - skalpelis 16y ago
    "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.

api 16y ago

Simplicity is harder to achieve than complexity. Try to solve problems by removing things, not adding them.

gaius 16y ago
The key to performance is elegance, not battalions of special cases - Alan Kay
- deleted 16y ago
  [deleted]
- neutronbob 16y ago
  The quotation comes not from Alan Kay, but Jon Bentley and Doug McIlroy. It's discussed here with Bentley: http://www.drdobbs.com/architecture-and-design/207000707 http://www.drdobbs.com/architecture-and-design/207000707

Roboprog 16y ago

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 :-)

Gonsalu 16y ago
It's not that funny...
- antipaganda 16y ago
  It was if this is the first time you'd come across the concept. :D

NathanKP 16y ago

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.

mcantor 16y ago

Code is the enemy. Code is weak. Code breaks. Coding is a last resort.

isnoteasy 16y ago

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.

jballanc 16y ago

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.

fierarul 16y ago
>he also directly made the code faster by being smaller. Only if you assume that there are no jumps (loops) in that code.

Eliezer 16y ago

A gear never breaks after it has been designed out of the machine.

eru 16y ago
But electronics just rot on the shelf, too.

exception 16y ago

Measuring lines of code is valid. The only caveat is that you must be intimately aware of whose lines of code you are counting.

itsadok 16y ago

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.

riccardom 16y ago

Not productive enough ;) "One of my most productive days was throwing away 1000 lines of code." -- Ken Thompson

binaryfinery 16y ago

"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."

RiderOfGiraffes 16y ago

Here's a previous submission of this item, along with its attendant discussion: http://news.ycombinator.com/item?id=1114223 http://news.ycombinator.com/item?id=1114223