
-2000 lines of code - aycangulez
http://folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt
======
spivey
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
_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
_Measuring programming progress by lines of code is like measuring aircraft
building progress by weight._ \- Bill Gates

~~~
machrider
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

~~~
daveungerer
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.

~~~
philologist
"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)

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

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

~~~
sreitshamer
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
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.

------
mian2zi3
The only thing better than writing code is deleting it.

~~~
peterb
Amen.

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

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

~~~
eru
But electronics just rot on the shelf, too.

------
Roboprog
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
It's not that funny...

~~~
antipaganda
It was if this is the first time you'd come across the concept. :D

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

------
jballanc
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
>he also directly made the code faster by being smaller.

Only if you assume that there are no jumps (loops) in that code.

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

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

~~~
gaius
The key to performance is elegance, not battalions of special cases - Alan Kay

------
RossM
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...](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)

~~~
dennisgorelik
Only wusses need comments in order to bloat their code. There are so many
"effective" alternatives.

~~~
RossM
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
infinite loops?

~~~
chc
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).

~~~
derwiki
i don't see anything that increments 'i'

~~~
chc
That would be because you don't see the body of the loop.

~~~
RossM
I did miss that out accidentally but I'm sticking like glue to your reason.

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

------
RiderOfGiraffes
Here's a previous submission of this item, along with its attendant
discussion:

<http://news.ycombinator.com/item?id=1114223>

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

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

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

