
-2000 lines of code - chanux
http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt
======
hibikir
My favorite anecdote on code removal comes from using Sonar, a static code
analysis tool.

At a previous job, a pretty smart architect decided that Sonar was a pretty
good tool to gauge code quality. He wasn't wrong. However, as a way to improve
code quality, management decided to make the continuous integration server
demand 90% test code coverage minimum, including branches, and no loss of code
coverage over half a percent from maximum, as measured by Sonar.

So I inherited a large, rather terrible application, which included a whole
lot of UI code using Swing. Swing has it's qualities, but being easy to write
meaningful tests for isn't one of them. So my predecessors often left some
chunks of frontend relatively untested, while making sure large amounts of
business logic was well tested. So to keep the application in order, I started
doing a bunch of refactoring. I cut the size of the backend in half, and all
the tests kept passing. But my commits were rejected by the build.

So if you have 10K lines of untested code, and 90K lines of very ugly, badly
factored, but tested code, you just couldn't remove 10K of the bad, well
tested code, because that would sink coverage metrics.

After much arguing for relaxing the rules, as I didn't think that adding tests
after the fact to bad UI code seemed like a good use of our time, I fixed it
in the only sensible way I could: Added an extra ten thousand lines of well
tested code that didn't actually run in production, but made the metrics
happy. Only then I could get the build to pass again.

~~~
warmwaffles
Terrible, but a necessary evil I guess. Sometimes you gotta just let sleeping
dogs lie and start removing unused code as you go.

------
baddox
There's a saying that goes something like "Measuring the progress of
developing software by lines of code is like measuring the progress of
manufacturing an airplane by kilograms of mass."

~~~
tjgq
Also reminiscent of this quote from Dijkstra [0]:

    
    
      My point today is that, if we wish to count lines of code,
      we should not regard them as "lines produced" but as
      "lines spent": the current conventional wisdom is so
      foolish as to book that count on the wrong side of the
      ledger.
    

[0]
[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html)

------
zwegner
At my last job I wrote a script to walk over git-log and add up all the line
number differences (skipping merges). By the time I left, my net code
contribution was something like -290kloc. I was the only person with a net
negative, though it was a smallish team.

With the sheer amount of bad code people write, I expect to do a lot of
deleting, refactoring, and rewriting, and I'd hope managers/fellow team
members would be able to see the value in that. But sadly, they usually don't.

~~~
PaulHoule
People also leave dead code around instead of deleting it. That dead code is
poison to the maintenance programmer because he's spend plenty of time trying
to understand what role it plays in the system of tracing a complicated bug.

I'd say it is open season on commented-out code. If code has been commented-
out since a few weeks it is good to delete it just as a matter of course.

~~~
jballanc
You should never commit commented-out code. That's what version control is
for. If you need that code back, just fetch it from the repo.

~~~
wmil
This is a bit of a tangent but I've been on teams that demanded you rebase
everything so that there's a linear history.

Of course this leads to nasty conflict resolutions, so they solve that by
squashing all of their commits before rebasing.

Now your code is no longer in the repo.

~~~
skybrian
But if it never appeared in the main branch then it doesn't really matter,
does it? You don't want to clutter up the history with experiments and false
starts.

~~~
wtetzner
I'm not sure that you don't. Having a history of how you got to the current
version could help future maintainers understand why you made the decisions
you did, and prevent them from making similar mistakes.

~~~
derekp7
I tend to work out of a private branch, and commit early and often. So I end
up with a lot of commits that say "fixed foo to be 1", then "oops, I meant it
to be 2", then "No, it should be -7", etc. I'll drop a tag, then rebase a
group of commits to re-order them (so all the fix, to a fix, to a typo mistake
that shouldn't have been there) are together. Then sometimes I'll drop another
tag, then squash, then rebase onto the main branch. Those temporary tags then
get pushed only to a separate repo that only I write to (the one that everyone
else uses gets the cleaned-up presentable code).

------
nemo1618
Though I've never used an Apple product, I adore folklore.org. So many great
tales of engineering. When I hear the word "hacker," these people come to
mind. A shame they didn't play a larger role in the company's direction (see
"Diagnostic Port"[1]).

[1]:
[http://www.folklore.org/StoryView.py?project=Macintosh&story...](http://www.folklore.org/StoryView.py?project=Macintosh&story=Diagnostic_Port.txt)

~~~
taiki
Thinking about the modern Mac Pro, I'm shocked to see people haven't
referenced this story more.

No internal slots, isn't this Steve Jobs' dream machine?

------
PythonicAlpha
Sometimes, less is more.

Some said: "A piece of art is only finished, when there is nothing left, that
can be taken away."

The art in computer programming is, to find ways to bring the problem to the
point, to find out what is really necessary to solve the problem (and not
more). This reduces (often, not always) the runtime, the amount of memory
needed -- and (most importantly!) the amount of maintenance that is needed.
The maintenance of a program is directly dependent on the number of code
lines.

Many companies start fast with a superior product, but than comes the time of
growth and growing demand, new employees are rushing in ... and the number of
lines explode. That is the point of danger. The company is about to strangle
itself. The number of errors are rising.

I remember an old, but once famous database product. The first 2 or 3 versions
where great and the company grew out of 4 developers to a horde. The next
version came out much much later than expected and was first a bug ridden
chaos. The problem: The number of employees and the number of code lines grew
faster than the company could manage them.

It is also said: "Adding new members to a late project, makes it later" That's
because of the overhead of managing those peoples and the added code does not
always add to project speed.

~~~
dalke
That first quote is from Antoine de Saint Exupéry.
[http://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry](http://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry)

Then again, "A work of art is never finished, it is abandoned."
([http://www.quoteyard.com/art-is-never-finished-only-
abandone...](http://www.quoteyard.com/art-is-never-finished-only-abandoned/) )

The database product sounds like dBase. If so, certainly management focus was
also a factor. [http://en.wikipedia.org/wiki/Ashton-
Tate#dBASE_IV:_Decline_a...](http://en.wikipedia.org/wiki/Ashton-
Tate#dBASE_IV:_Decline_and_fall_.281988.E2.80.931990.29) attributes it to a
push for Diamond. Its source material is unattributed. While
[http://www.dbase.com/Knowledgebase/dbulletin/bu03_b.htm](http://www.dbase.com/Knowledgebase/dbulletin/bu03_b.htm)
says it was a management push towards OS/2.

Your last quote is from "The Mythical Man-Month" by Fred Brooks(1975) and is
called "Brooks's Law".

~~~
paulbaumgart
Both statements about art are true: you will never achieve perfect simplicity,
but you should try to get as close as you can!

~~~
dalke
Minimalism is but one of many art styles, so I disagree with the goal of
achieving perfect simplicity.

~~~
paulbaumgart
Sure, but in the context of code and complexity, minimalism is your best bet.

~~~
dalke
You are against Easter Eggs, I gather? ;)

More seriously, of these two implementation for Python's str.lower(), which is
"minimal"?:

    
    
        for (i = 0; i < n; i++) {
            int c = Py_CHARMASK(s[i]);
            if (isupper(c))
                s[i] = _tolower(c);
        }
    
    
        for (i = 0; i < n; i++) {
            int c = Py_CHARMASK(s[i]);
            s[i] = _tolower(c);
        }
    

I suspect most would say the second is minimal, but the first is what Python
uses, because it's measurably and distinctly faster than the second, and that
extra performance is worth the extra maintenance overhead.

That's one reason I believe that programming-as-art metaphors don't really
apply. Minimalism as an art form not the same as minimizing the cost function
of different uncertain factors.

Anyway, this reminds me of a story from the Tao of Programming,
[http://www.canonical.org/~kragen/tao-of-
programming.html](http://www.canonical.org/~kragen/tao-of-programming.html) :

There was once a programmer who was attached to the court of the warlord of
Wu. The warlord asked the programmer: ``Which is easier to design: an
accounting package or an operating system?''

``An operating system,'' replied the programmer.

The warlord uttered an exclamation of disbelief. ``Surely an accounting
package is trivial next to the complexity of an operating system,'' he said.

``Not so,'' said the programmer, ``when designing an accounting package, the
programmer operates as a mediator between people having different ideas: how
it must operate, how its reports must appear, and how it must conform to the
tax laws. By contrast, an operating system is not limited by outside
appearances. When designing an operating system, the programmer seeks the
simplest harmony between machine and ideas. This is why an operating system is
easier to design.''

The warlord of Wu nodded and smiled. ``That is all good and well, but which is
easier to debug?''

The programmer made no reply.

~~~
paulbaumgart
Or, as Einstein put it, "It can scarcely be denied that the supreme goal of
all theory is to make the irreducible basic elements as simple and as few as
possible without having to surrender the adequate representation of a single
datum of experience."

Rephrasing for the software world: "...without having to make appreciable
sacrifices in user experience."

------
ChuckMcM
I love people who can leave a program functionally better with fewer lines of
_clear_ code. That last bit is important, obfuscated code is clever, but not
useful.

~~~
Gracana
> That last bit is important

Recently I've been learning that from two angles. First I'm realizing that
being a bit more verbose is often clear and safer. Second, I've been reading
and learning a lot about compilers, and I'm realizing that my "efficient"
(short) code and other trickery does diddly-squat, and the compiler will
produce the same code either way.

------
JoeAltmaier
My favorite optimization: replaced 10,000 lines of code that marshaled
structures in a Broadcom driver for transmission to the embedded processor,
with a single template of ~20 lines.

~~~
wlievens
Awesome. I once replaced an intern's 540 lines of code with 12 lines of my
own. Feels great.

~~~
knodi123
An intern? Don't pat yourself on the back TOO hard... ;-)

I once sped up an intern's code by just deleting a 30-line function, and doing
nothing else. Doofus didn't realize our language had a highly optimized built-
in sort, and so he wrote his own inefficient sort (insertion) that overrode
the existing one. Poor little guy was so proud of having chosen exactly the
right sort, and then implementing it based on his recollection of college... I
told him to spend the next few hours just reading the documentation of the
core API for our language.

~~~
AnimalMuppet
A quote I'm somewhat fond of: "A couple months in the laboratory can save a
couple hours in the library."

Unfortunately, I forget who said it.

~~~
Mindless2112
> A quote I'm somewhat fond of: "A couple months in the laboratory can save a
> couple hours in the library."

Isn't that backwards?

~~~
ISL
No. It's correct.

I can say this having spent months in the laboratory to learn things which
were already known. Who knew that precision quartz pressure gauges were called
'manometers' in the late eighteen-hundreds? I didn't, and thought I'd invented
something new for a couple months in my first year of grad school.

The adage is a good one. Reading a lot and reading widely pays off.

~~~
netcan
That idea might imply that future Google's, using its old self definition are
going to play an increasingly critical role in human progress.

------
leeoniya
"Perfection is achieved, not when there is nothing more to add, but when there
is nothing left to take away."

― Antoine de Saint-Exupéry, Airman's Odyssey

------
drdeadringer
One of the professors I had didn't like paperwork as much as we did, so he
shared a little [paraphrased] advice-story:

"Hey, I know you don't like this paperwork. I don't either, but I get asked to
do it all the time. My strategy? Give them as much paperwork as I can. These
forms, those memos, CCs on emails... eventually, sometimes, they ask me to
stop. 'You're giving us too much paperwork', they say. 'You don't want me to
give you paperwork? Works for me.'. So fill these out, and I'll take care of
the rest. Now, for today's class..."

------
ejk314
There's a quote I saw in a users' forum signature that's stuck with me; "My
best code was written with the delete key."

------
dang
No one seems to have pointed out yet that code size as a predictor of error
rates (and as a measure of complexity) is one of the few findings from
software engineering research that has been replicated many times. It's not
clear that the studies are very good, but at least they exist. We've discussed
this on HN more than once.

I'm longing for the day when people realize how significant this finding
potentially is.

~~~
amirmc
Every functional programmer I've met has pointed things like this out to me.
As well the ability to reason about smaller code-bases.

~~~
dang
Oh, yes. Me too. But they/we are a tiny minority with little influence over
industry practice. What I long for is the day that software organizations run
dramatically differently because of this principle. I think it's one of the
most profound things we know about software development, and it has huge
implications, but they're ignored.

Like any other powerful ignored truth—if that's what this is—its path to
acceptance will likely be through somebody doing something impressive with it
that hasn't been done before.

~~~
amirmc
I think Startups doing impressive things at scale will help with this. For
example, Whatsapp serving 500M people with code written/maintained by <50
engineers is an impressive story. What did they do differently? The post-hoc
stories about success rarely discuss the leverage achieved due to the
technology choices.

------
fsckin
Reminds me of this quote:

"One of my most productive days was throwing away 1000 lines of code." \- Ken
Thompson

------
habosa
In my opinion the best code is the shortest code/documentation that can be
understood in one or two reads by someone that is new to the codebase. Less or
more than that is bad.

exceptions are things like game programming, where certain hairy-looking
tricks can be necessary and have a real benefit. can't say the same for your
average web app.

------
georgeecollins
I came to a company last year where they were forecasting how they were
progressing on a project by counting the number of objects that had been
written. As in, the tech lead estimated the project would require like 200
object classes and some PM was crossing off objects as they were being
written.

Anyone who has completed a complicated functional program would probably
understand how that could be a misleading measure of progress and, worse, lead
people to spend time writing poorly engineered untested code. I think the
people who implemented this system understood that counting lines of code was
a dumb idea, but somehow thought this was better.

------
akramhussein
Couple years ago while still studying for CS, I did a telephone screen (with a
recruiter, not an engineer) with Microsoft and they asked me "how many lines
of code have you written in your career?" (at this point I didn't have a
career in SE). That was followed up by "what is the most number lines of code
you've written for a single project?". Other than scanning the diffs/commits
or using some reporting/metric tool, why would you care to keep count? Seems
like you are focusing on the wrong data points for recruitment and software
quality.

~~~
Zelphyr
The irony here is that when Microsoft was developing OS/2 for IBM, the latter
started requiring updates (similar to the OP) showing KLOC's written in a
week, and the then Microsoft engineers lamenting at how stupid that was.

Congratulations Microsoft. You've now become the bloated mid-80's IBM you used
to hate.

------
anon4
Well, another way to look at it is that you've improved 2000 lines of code.
That is, you have touched 2000 lines of code and modified them in a way that
makes the software better. Yes, you did delete all of them, but as a
professional expert you've discovered that these 2000 lines serve the project
better when not existing. Then, you wrote another 1000 lines of fresh code. In
the end, you've achieved a net betterment worth 3000 lines of code.

------
eskil
I worked for Andy Hertzfeld once, it was awesome in many ways, but the
anecdotes... so good.

------
everyone
I'd like to get your opinions on this...

I think programmers nowadays are a bit overly obsessed on getting lines of
code _down_

Its certainly possible to write something in one line when you could use 6 if
you use the more obscure and "fancy" tools available in the language you are
using. One thing that randomly springs to mind is linq in .net Reasons why
more lines might be better.

1\. The longer more explicit code might end up shorter and more performant
after it is compiled (like in the oldskool performance increasing trick of
unrolling loops)

2.When you come back to your fancy code later you may have forgotten about
that particular fancy trick and now you dont understand your code.

3\. Other people are less likely to understand your code.

4\. By using more specialised features in a langauge your code is now less
transportable to other langauges.

Personally I think the obsession with fewer lines quickly becomes counter-
productive and the main reason it is done is in order to show-off your
knowledge of these fancy things.

Note: I'm not talking about the guy in the article btw. Just talking a about a
general trend I've noticed in modern programming.

~~~
lmm
> 1\. The longer more explicit code might end up shorter and more performant
> after it is compiled (like in the oldskool performance increasing trick of
> unrolling loops)

Or it might be less performant. If you actually care about this, you should
have an automated test running regularly that will tell you one way or the
other. But most of the time it's not worth worrying about such things.

> 2.When you come back to your fancy code later you may have forgotten about
> that particular fancy trick and now you dont understand your code. > 3\.
> Other people are less likely to understand your code.

Or using fancy tricks more frequently can help you remember them. I think you
should use every feature available in the language - developers need to be
able to understand the language so that they can read third-party library
code. Or else have an automated system that flags usage of particular
features.

> 4\. By using more specialised features in a langauge your code is now less
> transportable to other langauges.

Who cares? Seriously, how likely is this to actually come up? If you've chosen
language X you presumably had a good reason for doing so; you should write
language X, not try and write language Y in language X.

Fewest lines of code is not the perfect metric, but I think it hits the sweet
spot: it's very simple to calculate, and captures a good proportion of the
difference between good code and bad code.

------
odbol
What's funny about this is that the YCombinator application actually asks you
how many lines of code your app is. I took the question as a chance to rant
about the irony of a software accelerator geared on making you an "software
expert" asking this question.

~~~
tlrobinson
If you've written 0 LOC for your revolutionary artificial intelligence system,
or 1,000,000 LOC for your "Instagram for Squirrels" app, I'm likely to be
equally suspicious. Otherwise there's a wide range of acceptable answers for
that question.

A rant probably isn't one of them.

~~~
rz2k
Somehow I imagine that Instagram for Squirrels necessarily _includes_ a
revolutionary AI system.

------
mproud
folklore.org is amazing, but it’s been around for 10 years now. I kinda want
to amend to the title: “(2004) (1982)”. Heh.

------
quantabytes
Take a look at the contributor's stats for the Bitcoin project on GitHub:
[https://github.com/bitcoin/bitcoin/graphs/contributors](https://github.com/bitcoin/bitcoin/graphs/contributors)
Gavin Andresen, the lead developer for the project, has removed more lines
than he has added.

------
xirdstl
At my last job, I was usually the one that cleaned up old or unused code after
we had gone through a design change or such. It was always very satisfying.
Not so much, though, for the poor chap whose code was usually the target of
deletion (through no fault of his own).

------
guelo
What do people think of commits as a metric? It's becoming more popular for
managers thanks to github's graphs.

~~~
senorprogrammer
I hypothesize that any numbers-based code metric management comes up with can
also be gamed by adequately-motivated developers. In fact, if you come up with
such a metric and have a developer who can't figure out a way to game it,
perhaps you want to consider letting that developer go.

Were I to work in a place with a 'git commits' metric for productivity, I'd
happily commit each line individually, to ensure that any potential data loss
was as limited as possible, of course.

To paraphrase Wally from Dilbert: "I'm writing myself a mini-van."

~~~
Uhhrrr
[http://www.klocwork.com/blog/wp-
content/uploads/2009/10/dilb...](http://www.klocwork.com/blog/wp-
content/uploads/2009/10/dilbert-minivan-small.png)

>if you come up with such a metric and have a developer who can't figure out a
way to game it, perhaps you want to consider letting that developer go.

Maybe that would be a good interview question (for a software manager): "How
would you game metric X"?

~~~
thefreeman
probably not. Seems to me like you are forcing the candidate to either look
stupid or dishonest.

~~~
Uhhrrr
Hm, how about, "How can metric X be gamed?", then?

------
yiedyie
Does anyone feel that those days are over.

~~~
senorprogrammer
Nope, there's more bad code being written now than at any other point in
history (I totally just made that fact up and I stand by it). If ever there
was a time to be hero through code deletion, now is the time. Carpe diem!

~~~
logfromblammo
If I didn't have so many bills to pay, I'd say that my current project would
work better on 20% of the current size of the code base. And yes, lines of
code is used as a team performance metric.

And since I was formally banned from using generics and lambdas and from
refactoring old code without explicit permission, I am no longer hurting the
team! Yay!

This is the worst job I have ever had.

