-2000 lines of code

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.<p>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.<p>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>Measuring programming progress by lines of code is like measuring aircraft building progress by weight.</i> - Bill Gates

“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.<p>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).<p>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.<p>Also, I am always wondering, how much more iterations are there until I get to some final, perfect, optimal solution.<p>Or will I really end up with one single line of code in the end? :)

The only thing better than writing code is deleting it.

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.

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 <i>this</i>: obvious big win, but a drastic opposite delta by your crude, misguided, metric!<p>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 <i>directly</i> 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.<p>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.<p>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.

Google Cache[1].<p>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...").<p>[1]: <a href="http://webcache.googleusercontent.com/search?sourceid=chrome&#38;ie=UTF-8&#38;q=cache:http://folklore.org/StoryView.py%3Fproject%3DMacintosh%26story%3DNegative_2000_Lines_Of_Code.txt" rel="nofollow">http://webcache.googleusercontent.com/search?sourceid=chrome...</a>

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:<p><a href="http://news.ycombinator.com/item?id=1114223" rel="nofollow">http://news.ycombinator.com/item?id=1114223</a>

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.