14 ms·
-2000 lines of code
- guelo 13y agoWhat do people think of commits as a metric? It's becoming more popular for managers thanks to github's graphs.
- senorprogrammer 13y agoI 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 13y agohttp://www.klocwork.com/blog/wp-content/uploads/2009/10/dilbert-minivan-small.png 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"?
- thefreeman 13y agoprobably not. Seems to me like you are forcing the candidate to either look stupid or dishonest.
- Uhhrrr 13y agoHm, how about, "How can metric X be gamed?", then?
- jerf 13y 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 13y agoOnly 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.
- LambdaAlmighty 13y agoRubbish, of course. But you're right in that it's becoming popular. Hiding a complex process behind a single number is oh so enticing. I've seen people submit a series of single-letter doc spelling fixes, each as a separate commit, to inflate the "activity" of both their projects ("Look! We've had over 2,000 commits! Project's HOT!") and themselves.
- mattgreenrocks 13y agoIt's not just managers: plenty of people go by this number and the recentness of activity, which rewards coding before thinking.
- davidgerard 13y agoPHB: "NO METRIC HAS BEATEN ME YET!!" http://dilbert.com/strips/comic/1994-11-21/ http://dilbert.com/strips/comic/1994-11-21/
- slackson 13y 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."
- JoeAltmaier 13y agoMy 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 13y agoAwesome. I once replaced an intern's 540 lines of code with 12 lines of my own. Feels great.
- knodi123 13y agoAn 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.
- budu3 13y agoCalling an intern Doofus is not a good attitude to take. Remember we were all programming noobs at some point.
- wicker 13y agoWhat language?
- AnimalMuppet 13y agoA 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 13y ago> 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?
- nemo1618 13y agoThough 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=Diagnostic_Port.txt http://www.folklore.org/StoryView.py?project=Macintosh&story...
- taiki 13y agoThinking 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 13y agoThere'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 13y 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
- zwegner 13y agoAt 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.
- taybin 13y agoI'd like to see that script.
- rav 13y agoHere 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
- zwegner 13y agoHa, nice, there's two options that definitely would've simplified my code (--numstat and --no-merges).
- porges 13y agoTo count by author: git log --numstat --no-merges --pretty=format:%an | awk ' author == "" { author = $0; next } /^$/ { author = ""; next } { added[author] += $1; removed[author] += $2 } END { for (author in added) { print author, "added", added[author], "removed", removed[author], "sum", added[author]-removed[author] } }' | sort -n -k 7
- taybin 13y agoThat is great! Thank you.
- baddox 13y agoThere'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 13y agoI 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 13y agoAnd 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.
- differentView 13y agoBill Gates has about as much to do with Windows 8 as William E. Boeing has to do with the 787.
- soperj 13y agoYou can say that about all of Microsoft's operating systems.
- jimmaswell 13y agoDidn't he have some contribution to MS DOS?
- joezydeco 13y agoOther than writing the check?
- odbol 13y agoWhat'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 13y agoI 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 13y agoWhy 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.
- odbol 13y agoI figured it was a trick question. My rant was still very informative about our product - we have a working app on 4 platforms (which share codebases to reduce amount of code written) and demo videos so I don't think I really needed to justify it with a number. My philosophy was that a developer should be judged on how few lines of code they take to make a working product, not how many.
- tlrobinson 13y agoIf 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 13y ago
- fsckin 13y agoReminds me of this quote: "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson
- PythonicAlpha 13y agoSometimes, 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 13y agoBTW there is a piece of art which contains only one character (space). It was written by Russian author Баян Ширянов (http://ru.wikipedia.org/wiki/Баян_Ширянов 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 http://lib.ru/PROZA/KLOCHKO/probel.txt
- dalke 13y agoThat 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-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_and_fall_.281988.E2.80.931990.29 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 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".
- akramhussein 13y agoCouple 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 13y agoThe 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.
- deleted 13y ago[deleted]
- ChuckMcM 13y agoI 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 13y 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 13y agoDoes anyone feel that those days are over.
- senorprogrammer 13y agoNope, 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 13y agoIf 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.
- davidgerard 13y agoThis 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 13y agoWhat do you mean?
- georgeecollins 13y agoI 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 13y agoWell, 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 13y agoI worked for Andy Hertzfeld once, it was awesome in many ways, but the anecdotes... so good.
- mproud 13y agofolklore.org is amazing, but it’s been around for 10 years now. I kinda want to amend to the title: “(2004) (1982)”. Heh.
- habosa 13y agoIn 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 13y agoI'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 13y agoI 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 13y 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 13y agoOne 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..."
- dang 13y agoNo 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 13y agoEvery functional programmer I've met has pointed things like this out to me. As well the ability to reason about smaller code-bases.
- dang 13y agoOh, 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 13y agoI 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.
- hibikir 13y agoMy 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 13y agoTerrible, but a necessary evil I guess. Sometimes you gotta just let sleeping dogs lie and start removing unused code as you go.
- kyllo 13y agoHaha. Test coverage requirements + no code review = just begging for this to happen.
- quantabytes 13y agoTake 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 13y agoAt 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).