-2000 Lines of Code (2004)

http://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt

by chanux • 12 years ago

317 139 12 years ago

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• 12 years ago

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

knodi123• 12 years ago

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.

Retric• 12 years ago

I once had the opposite happen, I wrote a ~12 line hack to get something to run which was replaced by ~10,000 lines of code that added no new functionality but was less 'ugly'.

nemo1618• 12 years ago

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

taiki• 12 years ago

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?

ejk314• 12 years ago

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

leeoniya• 12 years ago

"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

zwegner4• 12 years ago

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.

taybin2• 12 years ago

I'd like to see that script.

rav• 12 years ago

Here is a sample implementation:

    git log --author=rav --numstat --no-merges --pretty=format: |
        awk -e '{ a += $1; b += $2; } END { print a; print b; print a-b; }'

produces this output (sum additions, sum deletions, net line additions):

    112529
    85383
    27146

zwegner4• 12 years ago

Unfortunately I forgot to grab it off my work laptop when I got laid off. I would've liked to have stuck it up on github...

It wasn't really all that tricky though, it took me a few hours to write. git-log has options for only displaying the status line of diff-stat for each commit, and then displaying the parents of each commit, and the author. You look to see that there's only one parent (so it's not a merge), parse out the X added, Y deleted numbers, and stick them in a dictionary keyed by name.

A lot of the script was just getting statistics like average/min/max/stddev line counts, and printing them nicely.

jw2013• 12 years ago

Some people just don't understand that it's harder to maintain the code than to write new ones. They are probably not appreciating your refactorizations because they have not got to a point that it is almost impossible or super hard to write new code because the codebases are a large mess (they probably haven't got to this point because of your great refactorizations). But one day when they reach that point, I think they are probably going to miss and appreciate your past work.

PaulHoule• 12 years ago

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.

aparadja• 12 years ago

This is actually one of my favorite things about version control. If I know it's been committed at one point, I can delete anything and breathe the sweet air of clean code.

jballanc2• 12 years ago

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.

Lambdanaut• 12 years ago

Or better yet, ban commented out code from getting into the source tree altogether.

If the code is in past commits, there isn't a reason to muddy the source tree with it.

tshaddox• 12 years ago

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

brandonbloom• 12 years ago

I believe it was Bill Gates:

"Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs."

willemmerson• 12 years ago

And yet: Windows 8: 20gb (vs 1gb Ubuntu) Visual Studio: 2gb (vs 300mb Intellij) SQL Server: 5gb (vs 100mb Postgres) .net: 2gb (vs 20mb Python) (All guesses and silly comparisons, admittedly)

There seems to be quite a lot of lines of code there.

hnha• 12 years ago

Tangent: I once stopped logging visits on a website of mine because the actual metric I care about is the user interaction through comments (and using certain features on my site). I can highly recommend this if the anonymous visits to a site actually really don't matter to you.

yeldarb• 12 years ago

But then how do you know whether your lack of comments is because there isn't a large enough pool of potential commenters or if your content isn't engaging enough to incite them to post?

You're throwing away the top end of the funnel so it's impossible to know whether it's leaky or just completely dry all the way through.

tjgq2• 12 years ago

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

odbol• 12 years ago

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.

gpolak• 12 years ago

I seriously doubt they "rank" applications by KLOC, they just want to see if you have enough for a decent demo/prototype. Something that shows some implementation effort. And I suspect there's nothing wrong with zero if it makes sense in the context of that particular application.

stanmancan• 12 years ago

Why would you rant about this? You don't know what they're even looking for in an answer. How many LOC there are in your app is relevant but doesn't necessarily mean it's going to effect your application in any way. I think the history of some of the groups accepted speaks to this.

tlrobinson• 12 years ago

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.

Theodores• 12 years ago

"Instagram for Squirrels!" - great title for a pet project!

rz2k• 12 years ago

Somehow I imagine that Instagram for Squirrels necessarily includes a revolutionary AI system.

marcosdumay• 12 years ago

The "problem size"/"program size" ratio is very informative.

Demiurge• 12 years ago

Why is it ironic? Lines of code is a good estimate of complexity. The point of the article is that increase in complexity is not a good estimate of progress.

fsckin• 12 years ago

Reminds me of this quote:

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

PythonicAlpha• 12 years ago

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.

anonymfus• 12 years ago

BTW there is a piece of art which contains only one character (space). It was written by Russian author Баян Ширянов (http://ru.wikipedia.org/wiki/Баян_Ширянов ). AFAIK there is no English translation, but you can read it in Russian on http://lib.ru/PROZA/KLOCHKO/probel.txt

dalke4• 12 years ago

That first quote is from Antoine de Saint Exupéry. 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... )

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... attributes it to a push for Diamond. Its source material is unattributed. While 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".

paulbaumgart3• 12 years ago

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

akramhussein• 12 years ago

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.

_f1dq• 12 years ago

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.

ChuckMcM• 12 years ago

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• 12 years ago

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.

yiedyie• 12 years ago

Does anyone feel that those days are over.

senorprogrammer2• 12 years ago

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• 12 years ago

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.

davidgerard3• 12 years ago

This is why one of my greatest joys as a sysadmin (where "is it working wonderfully?" is the metric) is my occasional forays into the build infrastructure codebase with an axe. Less is always, always, more.

sukuriant• 12 years ago

What do you mean?

guelo• 12 years ago

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

senorprogrammer2• 12 years ago

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

Uhhrrr2• 12 years ago

http://www.klocwork.com/blog/wp-content/uploads/2009/10/dilb...

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

jerf• 12 years ago

"I'd happily commit each line individually, to ensure that any potential data loss was as limited as possible, of course."

Bah. While where I work has never even flirted with that metric, general agreement in my team was that the first thing to be done in the event that ever changed was write a git filter that committed one character at a time. I suppose you could take it further down to one bit at a time if you really wanted to; once you had the code for one character at a time, one bit at a time would be a trivial extension.

Less humorously, I've been complaining that our email notification system sends out a separate email for each commit in every new git branch... that is, if you are on a branch with 100 commits, and you take a new branch and commit that branch onto the server, our emailer seems to believe you just made 100 commits, and sends 100 emails. Or 1,000, as the case may be. One of these days that thing is going to take out the entire corporate email system.... of course, one never fixes the problem until it reaches that state, so I'm just waiting....

simias• 12 years ago

Only acceptable if each commit results in valid code without regression (if it doesn't build/parse or breaks everything it will make bisecting a terrible experience).

Making small atomic commits is actually good practice.

mattgreenrocks• 12 years ago

It's not just managers: plenty of people go by this number and the recentness of activity, which rewards coding before thinking.

davidgerard3• 12 years ago

PHB: "NO METRIC HAS BEATEN ME YET!!" http://dilbert.com/strips/comic/1994-11-21/

slackson• 12 years ago

"The more any quantitative social indicator (or even some qualitative indicator) is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor."

georgeecollins• 12 years ago

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.

anon4• 12 years ago

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• 12 years ago

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

mproud• 12 years ago

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

habosa• 12 years ago

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.

everyone• 12 years ago

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.

QuantumChaos• 12 years ago

I haven't seen much of this myself, although I can imagine it happening.

From what I've seen, bloated code tends to be code that is copied (either literally or in style) from somewhere else, which doesn't fit the task at hand. So you have functions that have lots of options, but only ever get called once with one set of parameters. The fix is to rewrite everything so that the abstractions are taylored to the task at hand.

What you are describing is a kind of excessive elegance. But this is fairly independent of the problem I described (and the article is describing).

I'll also say that there is a limit to bloat, and LOC is often a good guide to functionality. E.g. if I'm interesting in re-implementing something, I'll first look at the weight of the code. If I thought something would be a half hour job and the code is 5000 lines, I'll probably re-evaluate. Sometimes I've pondered reimplementing certain libraries, only to find they weigh in at a million lines of code.

lmm• 12 years ago

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.

drdeadringer• 12 years ago

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

dang2• 12 years ago

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.

amirmc2• 12 years ago

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

dang2• 12 years ago

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.

hibikir• 12 years ago

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.

warmwaffles2• 12 years ago

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

kyllo• 12 years ago

Haha. Test coverage requirements + no code review = just begging for this to happen.

quantabytes• 12 years ago

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

xirdstl• 12 years ago

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

-2000 Lines of Code (2004)

Related Stories