[HN Gopher] Negative 2000 Lines of Code (1982)
___________________________________________________________________
Negative 2000 Lines of Code (1982)
Author : pvillano
Score : 191 points
Date : 2022-11-05 16:48 UTC (6 hours ago)
(HTM) web link (www.folklore.org)
(TXT) w3m dump (www.folklore.org)
| Tempest1981 wrote:
| I assume the purpose of the form was to quantify the size of the
| change, to gauge the risk involved, and the QA effort required.
|
| Is there a better way to gauge "churn" or risk? Cyclomatic
| complexity deltas?
| msoad wrote:
| I know lines of code as a measure of productivity has been
| criticized to death here and elsewhere but today I went and did
| some analysis on past two years of my team members contributions
| and saw the team members that I know they are productive are
| modifying code a ton more than others. It can be subtraction of
| code too but overall more changes correlated with my perception
| of their contributions. My perception is pretty informed because
| I'm their manager and I know this team and this code base very
| well.
| johannes1234321 wrote:
| Amount of code can be an indicator, however as soon as
| developers know it is being used as metric it is easy to
| manipulate.
| expazl wrote:
| No, it's not easy to manipulate. You're thinking in linear
| terms which isn't what lines of code changed is useful as.
| You can't use it to distinguish which of 4 different
| productive programmers is most or least productive. However
| it's extremely easy to distinguish the non-productive
| programmer in the group of 5. And it's not easy to fake,
| because as soon as that developer start merging in a ton of
| bogus or useless edits to push up their numbers then everyone
| on the team, including the manager will call them on their
| bullshit.
|
| It's just like shift times for workers in manual labor jobs.
| You can't tell which of the people who are meeting up 8 hours
| a day is most productive based on if they where there for 8
| hours and 12 minutes or 8 hours and 25 minutes. But you sure
| as hell can easily see that if someone is showing up 4-5
| hours on a nine-to-five job, then something is wrong. And if
| that person tries to "fake it" but showing up for 8 hours but
| spends half the time slacking off, but coworkers and managers
| will call him on the bullshit.
| johannes1234321 wrote:
| Let me commit node_modules! And automate regular updates.
| Baam I've got a huge loc count. True, I ha e to argue why I
| do it and I say for auditing and reliability and maybe win.
| Once that is through I reformat the code even so slightly
| (rewrap comments?)
|
| And when I then do actual work in between I lean towards
| the solution giving me more lines. Longer variable names,
| more line breaks, ...
|
| There are so many ways to manipulate that, one I know it's
| a key metric. Sure, it's hard to go from weakest to top
| contributor that way, but good enough to get away from last
| spot who is being fired. At least till all play that game.
| By then the project goes towards a wall.
|
| So yes, for a one off case to identify engineers one should
| talk to it is a somewhat useful metric, but I would look at
| more business relevant metrics like amount of closed bugs
| or similar first (while of course they can be manipulated
| easily as well ...)
| BlargMcLarg wrote:
| Your entire point revolves around the idea of coworkers
| ratting out and being smart enough to know. Not every place
| is so cutthroat and pro-employer this is a given.
|
| The idea the _manager_ would call out individuals is
| laughable too. Most managers barely know how to code
| themselves. Give it another few decades before your manager
| looking through commits is a standard, you 're more likely
| to see alert tools be prevalent before that.
| cerved wrote:
| it's easier for me to fake then you to check
| still_grokking wrote:
| It is easy to manipulate.
|
| You just need to create a shitload of bloated bullshit that
| somehow "works" (at least more or less).
|
| That doesn't make you productive.
|
| Actually that's even counterproductive as it creates
| technical debt. But by the bogus metric that would be
| positive.
| wsc981 wrote:
| If the team verifies PRs, then it _should_ be hard to get
| most bogus commits merged in the repo though.
| still_grokking wrote:
| Sure, in an ideal world no bugs and not even bad code
| would slip through review.
|
| I'm still to find the place where this is true in
| software development.
| vidarh wrote:
| Creating bloated bullshit has even more value in terms of
| measured changes than the initial bloat because it also
| creates the opportunity to fix it up later for even more
| changes.
| AnonCoward42 wrote:
| "When a measure becomes a target, it ceases to be a good
| measure." (short form of Goodhart's law)
| grogers wrote:
| LOC definitely positively correlates to productivity, it just
| isn't everything. One year I modified over a million lines,
| because we decided that we wanted to stored some generated data
| in a config file that was checked into git, rather than in the
| DB. If you can ignore certain commits like this, the
| correlation is probably even better, but use it as just one
| data point.
|
| Another major confounder is that super deep investigations that
| fix major problems often have relatively trivial solutions at
| the end. But the effort to debug and fix them (that is largely
| hidden by conventional metrics) is enormous. The people working
| on these types of things are often your best devs (because you
| know they will actually get to the root cause), but if you are
| only looking at LOC you wouldn't know that.
| armchairhacker wrote:
| LOC modified is a fine rough estimate. The issue is that it's a
| _rough_ estimate and shouldn 't be used in things like who to
| promote or fire without deeper investigation.
|
| Usually LOC modified correlates with actual productivity but
| there are lots of exceptions. Like if someone copies an open-
| source library directly into the repo, commits a formatting
| change, is working on a critical section of code, is working in
| a different language, is writing new features while everyone
| else is fixing bugs, has been told they are going to be
| measured by LOC, etc.
|
| The fact that you actually analyze your team members'
| contributions, know the codebase, and measure productivity in
| more ways than LOC is a good sign. The problem is when managers
| exclusively measure LOC to gauge productivity and make
| decisions. While LOC and productivity correlate more often than
| not, I bet you can spot at least some cases where the LOC is
| not an accurate measure.
| gburt wrote:
| Counting lines of code, commits, changesets or any other simple
| metric will destroy your culture.
|
| The team _will_ find out, and then instead of contributing to
| the success of the business in earnest, they'll be doing stupid
| things like maximizing their changesets or racing for "easy"
| large changes like deleting a module.
|
| It doesn't matter whether those values do or do not correlate
| with reality (IMO, if they do, it is for relatively junior
| engineers only). If you give off the smell of measuring people
| like that, you will ruin any collaborative team environment and
| you risk never being able to recover that.
|
| There's a good chance you'll chase away excellent engineers
| with this sort of low-effort metrics management too.
| gedy wrote:
| I think the key point is modified, not just net new lines.
| About 15 years ago I worked for a genius manager who had his
| underling write a script to measure productivity this way, and
| they forgot to account for removing lines of code. They were so
| pleased with the one guy who just loved to copy paste crap over
| and over, versus us who were actually refactoring or reusing
| existing code.
| greenthrow wrote:
| Things LOC doesn't measure:
|
| - patents written / rewritten / meetings with lawyers / issued
| - mentoring of other engineers - PRs reviewed - talks given -
| meetings attended - RFCs / ADRs written - customer calls
| attended - quality of code (the original and best reason that
| LOC is bad.)
|
| Et cetera, et cetera
|
| If you are truly an engineering manager, unless all your direct
| reports are fairly junior, I sincerely hope you realize soon
| that LOC is a pretty terrible measure of engineer contribution.
|
| I am old enough to remember when the industry finally came
| around to accepting LOC is a worthless measure of engineer
| productivity in the late 90s. I am not exactly shocked but
| dismayed that this conversation needs to be rehashed.
|
| Number of tasks closed is a better measure than LOC and it is
| still a terrible measure.
| koonsolo wrote:
| At the company I'm currently working, they accept that
| seniors crunch out less code than juniors. Because of all the
| "side jobs" you listed.
| malux85 wrote:
| Lines of code written
|
| Lines of code rewritten (changed N days after)
|
| Lines of code removed
|
| Lines of code that contributed to linting problems
|
| Lines of code that contributed to security issues (as reported
| by the static analyser)
|
| Average complexity measures
|
| CI/CD build failure rates
|
| Lines of code reviewed
|
| Gitlab has plugins to generate reports like this, and if you
| have enough data (multi year preferably) you can use this as a
| springboard for deeper analysis of members of the team, I find
| all these metrics together (non taken as absolutes because
| there's many assumptions built into each one) can give a good
| overview of individuals in a team
| BlargMcLarg wrote:
| Review + written encourages buddy-buddy dynamics.
|
| Build failure rates encourages frustration as long as you
| don't provide ways to run the exact tests in isolation
| locally, under the same rules as CI. Meanwhile, branch
| triggers and pre-push hooks trivialize this further.
|
| Most of these metrics are strange given they are trivial to
| check pre-merge. Meanwhile, running these statistics pre-
| merge discourages small commits and sharing code prior to
| having ideal builds.
|
| The moment this gets out is the moment devs will game your
| statistics and any benefit you gain goes out the door. And
| almost every one of these, even combined, is easy to game.
| malux85 wrote:
| Correct, we do not tell the devs these are being measured
| BlargMcLarg wrote:
| I cannot tell if you are aware you're setting devs up for
| failure or not. Half your mentioned metrics are tackled
| by hard forcing your devs to run branch CI prior to
| merging and giving them a slap on the wrist for not
| running CI checks locally pre-push.
|
| If they are important enough to measure, why not hard
| force them and focus on the remaining metrics instead?
| malux85 wrote:
| See where I said "none taken as absolute because there
| are assumptions in each one"
|
| And
|
| "Use these as a springboard for deeper analysis of devs"
|
| These are only used as high level metrics to guide
| further analysis, we are keenly aware of the faults of
| these metrics - but the alternative of no-metrics or
| worse, "gut feel", is slow and riddled with more
| problems.
|
| It doesn't mean a dev is bad, maybe it means there's some
| tooling failure, or organisational problem, or personal
| problem they need help with. These metrics give
| visibility into anomalies, and their imperfect nature
| doesn't mean they are useless.
|
| There's also like 20 more metrics but I'm on my phone and
| couldn't recall them all right now
|
| Also I don't know where all of this nonsense about
| "forcing" to run CI/CD before branch merges and "slap on
| the wrist" - all our devs can run the test suites locally
| in docker and inside their IDE, nobody is forced to do
| anything in the pipeline severs, and also nobody gets a
| slap on the wrist for CI/CD failures, actually I like to
| see larger changes with more failures because it means
| the dev is trying and I consider this normal behaviour,
| your incorrect assumptions about our test environment and
| how we interpret these metrics sound like you're
| projecting.
| still_grokking wrote:
| I'm not sure.
|
| > Lines of code written
|
| Less is better, right?
|
| Because it's really easy to throw code at a problem.
|
| OTOH it's hard to come up with an optimal minimal solution.
|
| > Lines of code rewritten (changed N days after)
|
| Means: Your devs commit unfinished, not thought out crap.
|
| Or: Management is a failure because they change requirements
| all the time.
|
| > Lines of code removed
|
| More is better, right?
|
| Because cleaning up your code constantly to keep it lean is
| key to future maintainability.
|
| But could be also a symptom of someone with a NIH attitude.
|
| Or, management is a failure because they don't know what they
| want.
|
| > Lines of code that contributed to linting problems
|
| If it's more than zero that's a symptom of slacking off and /
| or ignorance.
|
| Your local tools should have showed you the linting problems
| already. Not handling them is at least outright lazy, and
| maybe even someone is trying to waste time by committing
| things that need another iteration later on.
|
| Or, your linting rules are nonsense, and it's better to
| ignore them...
|
| > Lines of code that contributed to security issues (as
| reported by the static analyser)
|
| Quite similar to the previous.
|
| Ignorance or cluelessness. Maybe even the worst of form of "I
| don't care", while waiting whether your crap passes CI.
|
| In case someone doesn't know how to handle such warnings at
| all you have a dangerously uneducated person on the team...
|
| Or, what is at least equally likely: Your snack-oil security
| scanners are trash. Producing a lot of the usual false
| positives (while of course not "seeing" any real issues).
|
| > Average complexity measures
|
| Completely useless on it's own.
|
| Some code needs to be complex because the problem at hand is
| complex.
|
| Also more or less most of this measures are nonsense. The
| complexity measure goes usually down when you "smear" an
| implementation all over the place. But most of the time it's
| more favorable to concentrate and encapsulate complex parts
| of your code. Hundred one-line methods that call each other
| are more complex than one method with hundred lines of code.
| But the usual complexity measure would love the hundred one-
| liners but barf at the hundred line method.
|
| If there's someone who constantly writes "very complex" code
| (according to such measure done by some tool) this can mean
| that this person writes over-complicated code, as it could
| mean that this person is responsible for some complex parts
| of the code-base, or is consolidating and refactoring
| complexity that was scattered all across the place. Or maybe
| even something else.
|
| > CI/CD build failure rates
|
| This means people can't build and test their code locally...
|
| Or someone is lazy and / or ignorant.
|
| Or, equally possible, your CI/CD infra is shit. Or the people
| responsible for that are under-performers.
|
| Or your hardware is somehow broken...
|
| > Lines of code reviewed
|
| How do you even measure this?
|
| Just stamping "LGTM" everywhere quickly would let this
| measure look good. But is anything won by that? I guess the
| contrary is more likely.
|
| Also someone who's only constantly complaining about others
| code would look good here...
|
| OTOH valuable and insightful code review is slow, takes a lot
| of time and effort but does not produces a lot of visible
| output. That's why I think it's disputable whether this can
| be measured even in a meaningful way.
|
| There is only one valid way to asses whether someone is
| productive: You need to answer the question whether what this
| person is doing makes sense in the light of the stated goals.
|
| But to answer this you need to look at the actual work /
| things produced by the person in question, and not on some
| straw man proxy measures. All measures can be gamed. But
| faking _results_ is much harder (even still possible of
| course).
| [deleted]
| [deleted]
| grensley wrote:
| I would love love love to see a study on the correlation between
| lines of code (not net, total changes + and -) and co-worker
| assessment of aptitude for people in the non-inclusive band from
| Junior to Architect (aka, people who are really expected to write
| a bulk of the software).
| sdeframond wrote:
| I light of recent Twitter events, I wonder what Musk would think
| of this...
| bheadmaster wrote:
| Is there any evidence that Musk is evaluating Twitter employees
| based on the LoC written?
|
| There's been so much fake news regarding Twitter and Musk these
| days that I honestly can't tell anymore.
| sillysaurusx wrote:
| I had the same thought. It's one of those stories that we'd
| love to believe, just because it's so incendiary. But the
| original source seemed to be an unsourced tweet, and it's not
| a good idea to believe those.
|
| I'd be interested in evidence too.
| pfoof wrote:
| So that's why Git shows both + and - numbers.
|
| Either way, with such management...
| KerrAvon wrote:
| Oh, there's definitely value in seeing that in a PR diff. I
| don't think that's a management thing per se.
| PragmaticPulp wrote:
| No metric can or should be used in isolation to evaluate
| productivity.
|
| LOC is obviously very flawed, but to be completely honest it has
| been useful as part of a heuristic for figuring out where
| something has gone wrong in a department (after applying basic
| heuristics like removing packaged code, vendored stuff, etc.)
|
| For example, if engineers are constantly committing and then
| deleting huge amounts of code (somewhat like this example) then
| it's good to dive in and make sure you don't have some issues
| creating that situation. This can range from product managers who
| aren't validating their requests before engineers start working
| on them, to interpersonal issues such as unqualified juniors
| writing large amounts of buggy code and leaving it for senior
| engineers to fix.
|
| These metrics can also be warning signs that something has gone
| wrong. If an engineer's number of commits have plummeted and LOC
| committed has gone way down, it's a sign that you should ask more
| deeply how their work is going. I've had situations where
| programmers were being pulled into 20+ hours of meetings each
| week and being given weird research assignments from random
| C-level executives that took away all of their coding time. I've
| also had situations where people weren't getting along with each
| other in private and DMs, and the first warning sign was that
| their contributions stalled.
|
| So while LOC and commit metrics can absolutely be misinterpreted
| in the wrong hands (e.g. as a proxy for laying off Twitter
| employees without trying to understand the context of their work)
| I've actually found them to be helpful as one of several early
| warning systems that something is going wrong with a team or
| project. Work with people for a while and it's not hard to
| recognize their normal output and when it has stalled for
| unexpected reasons. Use that as a signal to start a conversation
| about how they're doing.
| nonethewiser wrote:
| I setup prettier and ran it against our codebase. Guess I'm the
| CTO now.
| jspash wrote:
| The first thing I look at when reviewing a pull request is the
| total lines of code added and removed. If the number is over a
| certain amount (it differs depending on the language and task) I
| will immediately reject it and ask for a one-on-one. Too many
| additions or deletions are a signal that something went wrong
| somewhere. Either the dev went off piste or the task wasn't
| properly specified. Or sometimes an auto-formatter has gone on
| the fritz and "prettiered" everything up.
| choeger wrote:
| But he didn't write -2000 lines of code, did he? He wrote a _new_
| algorithm that was 2000 lines shorter than the old one. So, in
| principle, there was a positive number of lines that could have
| been reported.
|
| Of course, loc is a bad goal for productivity, but it can still
| be an interesting _measure_ (similar to test coverage): If I
| count lines of code added, commits, or tickets closed, I cannot
| compare any two developers. But if I count that metric for the
| same developer, or the same team, I can certainly spot changes in
| productivity. (As every metric has its outliers it would probably
| be. best to combine all of them.)
|
| So if I was managing a team and wanted to know if it would be
| beneficial to optimize test execution times, I could just rent
| some bigger machines and see what happens. I could also do a
| similar experiment with organizational aspects like the size and
| schedule of meetings or the introduction of a dedicated on-call
| contact for support requests, etc.
| gmiller123456 wrote:
| >But if I count that metric for the same developer, or the same
| team, I can certainly spot changes in productivity
|
| I can't imagine this working in any scenario. Even different
| tasks within the same project on the same day will involve
| enormously different amounts of coding, testing, and analysis.
| iLoveOncall wrote:
| > If I count lines of code added, commits, or tickets closed, I
| cannot compare any two developers. But if I count that metric
| for the same developer, or the same team, I can certainly spot
| changes in productivity.
|
| No you can't.
|
| Sometimes I will be working on coding related tasks for months,
| and then mostly on design tasks for months. I am not more or
| less productive in either, but I will close a lot less tickets
| and write 0 lines of code when I'm doing design-related work.
|
| Same with oncall. I probably won't write much code but I can
| close a hundred tickets in a week.
|
| Metrics are just a stupid measure of an engineer's
| productivity.
| [deleted]
| SonOfLilit wrote:
| No, you can't. There is barely any correlation between the
| amount of new lines of code I wrote in a day and how productive
| I was that day.
|
| As a senior technologist who bills his time as a consultant, I
| can tell you that I (correctly) get paid the most for days
| where I write 0 lines of code.
|
| But also, my most valuable code was code where I spent a week
| thinking and writing maybe 5 lines of code a day, and my least
| valuable code was when my output was limited by my typing
| speed.
| ShredKazoo wrote:
| Alternative proposal: Count the number of commits devs are
| making. Since some devs make more frequent commits than
| others, for each dev review some fraction of their commits at
| random, and rate how substantial the randomly sampled commits
| are. Then multiply average commit importance by number of
| commits to get an overall productivity score.
|
| Thoughts? I think the biggest counterargument is that it
| incentivizes churn like making a commit and then reverting it
| later.
| BlargMcLarg wrote:
| Your ratings are going to be somewhat arbitrary and the
| moment this comes out, you'll risk Goodhart's Law anyway.
|
| Besides, you might as well start counting closed number of
| issues/tasks/tickets, story points or whatever, and skip
| the commit count altogether.
| prerok wrote:
| Yeah, and that has another problem: developer who code
| fast but don't think things through would have plenty of
| issues opened against their code. They would probably be
| fixing them as well so their close count would be much
| higher than for a programmer that made the right choices
| to begin with.
|
| You could then go with features only tickets but those
| vary in size and complexity. Now, if we would put
| complexity as a measure (on which the team of developers
| should agree) and then measure the number of issues on
| that implementation we might get a better measure of that
| person's contribution.
|
| That said, once that would be in place, even that can be
| gamed.
|
| I think there is no silver bullet here, as much as we
| would like it to exist.
| eckza wrote:
| Alternative proposal: for the love of God, please stop
| trying to quantify this.
|
| If your engineers truly aren't getting shit done, you
| should be able to tell without looking at their code.
|
| We don't get paid to write code. We get paid to _think_;
| it's just that if we don't write code afterwards, we get
| fired.
| dsr_ wrote:
| Programming is the reification of decision making
| processes.
|
| Therefore, a language that allows a programmer to turn
| thoughts into correct code faster is a win.
|
| The size of the code as writter is only slightly
| interesting: almost everyone can type faster than they
| can think clearly. A more compact notation is preferred
| for reducing the delay between typing and testing, but
| not to the point of impairing readability.
| kjksf wrote:
| I'm not saying that measuring programmer's productivity by lines
| of code written is good.
|
| This story, however, is not a story of someone who deleted 2k
| lines of code.
|
| It's story of someone who wrote, let's ballpark, 4k lines of code
| and then rewrote them, which resulted in 2k lines of code left.
| Not sure how to account for that but let's say it's 5k lines of
| new code written in total which ended up as 2k loc.
|
| This story does not prove that you are a great programmer if you
| write little code. It actually shows that even the best of the
| best (like Bill Atkinson) write a lot of code and cannot arrive
| at the ideal code at the first try. Writing the first 4k loc was
| a necessary step to gain knowledge that enabled him to refactor
| the code down to 2k loc.
| pdpi wrote:
| For one of the most frustrating projects I ever worked on, my
| net contribution was in the vicinity of -1k to -2k LOC in a
| service that weighed in at around ~5k LOC in the end.
|
| The guy who started the project came from an enterprise Java
| background, and his code was the stereotypical design pattern
| pileup. I only jumped in because he was having trouble actually
| wrapping it up, and, with every commit, I deleted a bunch of
| code and replaced it with just a small fraction of what was
| there before, and he reviewed the changes and agreed they were
| an improvement.
|
| Yet, even though he genuinely agreed his code was overly
| complicated, he never internalized the learnings, and kept
| repeating the same mistakes over and over again. He was fixated
| on the idea that his coded needed to be extensible (without a
| clear notion of how or why) and kept adding abstraction after
| abstraction for every new feature he added.
|
| So, yes. It is uncontestably true that you often need to write
| 4k LOC before you understand how to write the same thing in 2k
| LOC. But it's also very much the case that there's a baseline
| of skill you need to write those 4k LOC instead of a 10k
| monstrosity.
| pencilguin wrote:
| > _He was fixated on the idea that his code needed to be
| extensible (without a clear notion of how or why) and kept
| adding abstraction after abstraction for every new feature he
| added._
|
| Sad to say, usually the only way this lesson can be learned
| is through being fired. And not always then, but at least it
| is no longer your problem after.
| pjc50 wrote:
| It doesn't specify whether _he_ wrote the 4kloc first ..
|
| Negative LOC is not uncommon in maintenance work; things become
| obsolete or better solutions are invented.
| pencilguin wrote:
| He did. Or anyway the first version. Possibly other people
| dirtied it after.
| mepiethree wrote:
| There are any number of counter examples to most of these
| metrics, but I think the extreme counter examples are often in
| bad faith. You can't convince me that a JavaScript engineer who
| consistently authors 1 commit a month is productive. At some
| point, you need to stop talking about stuff and actually build
| stuff
|
| Of course you can't determine the best person by lines of code
| (package.lock files lol) but you can often make a guess at the
| worst person
| ihateniggas wrote:
| [deleted]
| tootie wrote:
| "Measuring programming progress by lines of code is like
| measuring aircraft building progress by weight." - Bill Gates
| lelandfe wrote:
| That's one of the most effective analogies I have ever heard.
| Will be reusing, thanks.
| hinkley wrote:
| There's an old aerospace joke about how the cost per pound of
| airplane equipment has been continuously going up and at some
| point the only way to maintain the line is if some of the
| equipment weighed 0 lbs. Hence the introduction of software.
| KerrAvon wrote:
| LOC is the refuge of the incompetent. At Apple, when Gil Amelio
| came on board with Ellen Hancock etc, one of the first things
| they asked for was a total LOC estimate for Copland. There was a
| lot of pushback because engineering knew it was meaningless but
| they said they wanted it anyway. I don't know what they did with
| it.
|
| The ex-NeXT management who took over from them never asked for
| LOC.
| andirk wrote:
| All of the worst code I have seen is MANY, MANY LOC!
| Copy/paste, very not DRY, names of things that have lost
| meaning.
| vbezhenar wrote:
| For me LoC is a good initial metric. I don't know why everyone
| refuses it outright. Yes, there're cases where someone will
| spend month just to delete 1 line and that would be productive.
| Or when someone will autogenerate 10k LoC spending 5 minutes.
| But keeping it in mind I still use LoC as initial metric when I
| need to estimate PR complexity or project complexity. I guess
| it should not be the only metric and it definitely should not
| be the metric which is used to estimate someone's productivity,
| at it's very easily gamed.
|
| It's good because I need few shell commands to measure it.
| kragen wrote:
| It's useful for telling how much effort went into a software
| system, and how much it will cost to maintain it, but it's
| not useful for telling how much effort went into a task, even
| when it's not being gamed.
|
| It also doesn't tell you how much effort _should_ have gone
| into a software system. Spend six months writing your own
| message queue? 16384 lines of code. Spend two weeks wiring up
| your system to RabbitMQ? 1024 lines of code.
| MBCook wrote:
| Right. I can see it as a relative metric. A 20k LOC project
| is _probably_ less complicated (complexity, features,
| screens, whatever) than a 200k LOC project.
|
| Not always. LibreSSL is probably smaller than some
| applications but _much_ denser with complicated code than a
| simple system with lots of CRUD screens.
|
| But it's an easy to grasp metric. It's also quite easy to
| figure out. It's automated and doesn't require weeks of
| study by specialists.
|
| But as we all know, using it to manage productivity of
| individuals or teams can be heavily misleading.
| njharman wrote:
| There're tools that analyse and report on code's actual
| complexity. Using, ya know science.
| LtWorf wrote:
| There is more to complexity than how nested something is.
| fragmede wrote:
| Can you name some? I'd be interested in trying them out.
| For, y'know, science.
| fwip wrote:
| It's usually a sort of shibboleth (or the opposite of one?) -
| somebody asking about LoC, especially a new manager, sends up
| alarm bells of "this person doesn't understand coding."
| fragmede wrote:
| Because it's so obviously easily gamed. There are some very
| specific contexts in which LoC is actually useful. A codebase
| with 1M LoC is vastly different to deal with than one with
| 100,000, no matter the language.
|
| Goodhart's Law: when a measure becomes a target, it cease to
| be a good measure.
| dang wrote:
| Related:
|
| _-2000 Lines of Code_ -
| https://news.ycombinator.com/item?id=26387179 - March 2021 (256
| comments)
|
| _-2000 Lines of Code_ -
| https://news.ycombinator.com/item?id=10734815 - Dec 2015 (131
| comments)
|
| _-2000 lines of code_ -
| https://news.ycombinator.com/item?id=7516671 - April 2014 (139
| comments)
|
| _-2000 Lines Of Code_ -
| https://news.ycombinator.com/item?id=4040082 - May 2012 (34
| comments)
|
| _-2000 lines of code_ -
| https://news.ycombinator.com/item?id=1545452 - July 2010 (50
| comments)
|
| _-2000 Lines Of Code_ -
| https://news.ycombinator.com/item?id=1114223 - Feb 2010 (39
| comments)
|
| _-2000 Lines Of Code (metrics == bad) (1982)_ -
| https://news.ycombinator.com/item?id=1069066 - Jan 2010 (2
| comments)
| slantedview wrote:
| The difference between those posts and this one is context,
| since in the past week we've seen LoC being used as a metric to
| determine mass layoffs at a prominent tech company.
| tonnydourado wrote:
| Well, it is a damn good story. People might have gone overboard
| on 2010, but every 18 months seems like an acceptable rate, to
| get new people introduced to the tale =)
| dang wrote:
| Oh yes. The purpose of 'related' lists to give people more
| (hopefully) interesting stuff to read--not to scold anybody!
|
| Reposts are fine after a year or so (this is in the FAQ:
| https://news.ycombinator.com/newsfaq.html) and the for
| perennial classics, occasional reposts are important so more
| recent user cohorts can get steeped in the culture
| (https://news.ycombinator.com/item?id=32405060).
| cathdrlbizzare wrote:
| Dead Code Society ftw
| gcanyon wrote:
| I like this one almost as much as "And then he discovered loops!"
| https://www.folklore.org/StoryView.py?project=Macintosh&stor...
|
| I use the loops one more often in discussing development.
| xyzzy4747 wrote:
| Of the several engineers I've managed at my startup, the ones who
| wrote the most code got the most stuff done. It's a correlation
| and there are exceptions, but it's generally the case, at least
| for new software. A project won't complete itself without a lot
| of code being written or modified. Although I think total number
| of PRs is possibly more useful as a metric than total LOC
| (assuming neither are being gamed).
| LtWorf wrote:
| I know people who write quickly huge amounts of very poorly
| thought of code that will be buggy and will have a bunch of
| completely useless functions, reimplemented functions that
| already existed within the project and similar stuff.
|
| You might be unaware that you are not such a great manager.
| slantedview wrote:
| I love that 40 years later, a prominent tech company leader still
| has yet to learn the lesson of this story.
| pjc50 wrote:
| People _love_ reasoning things from first principles rather
| than learning.
| sixstringtheory wrote:
| Isn't reasoning things from first principles exactly how you
| learn?
|
| I think what you meant was that people love learning lessons
| the hard and slow way instead of taking others' word for it.
|
| I'm sort of conflicted on this. Yes, it is faster to take an
| expert's word for it. But after a couple of human generations
| of that, do we actually lose understanding?
|
| I think we can only stand on the shoulders of giants standing
| on the shoulders of giants to some N giants until the whole
| acrobatic totem pole comes tumbling down. The game of
| telephone through the ages produces belief, not
| understanding.
|
| Another option is making giants more giant, but that is an
| even slower process than one person learning from first
| principles: humanity has to find a way for our brains to
| learn those principles faster. Maybe that will take millions
| of years of evolution. Or maybe something like neuralink will
| provide a shortcut so it only takes thousands of years.
| anonymousiam wrote:
| Seems like whenever I write a bunch of code, it's always bigger
| before I've completed the test/debug phase. I put this down to
| revisiting all the algorithms while finalizing the code, and
| making adjustments/optimizations where it makes sense.
| ChrisMarshallNY wrote:
| I do a lot of that. Also, when I review the code documentation.
| I will sometimes, completely rewrite methods.
| Wowfunhappy wrote:
| Allow me to play devil's advocate for a moment:
|
| Most good writers will tell you that shorter is almost always
| better. You want to express your thoughts in the most succinct
| way possible. Review your own writing to remove as much as you
| can, then hand your draft off to an editor who'll try to cut even
| more.
|
| And yet, many writers are still paid by the word, and many book
| contracts still specify target page counts. Because even though
| shorter is better, the shortest possible length of a given text
| still serves as a rough measure of that text's breath and
| complexity.
|
| Is code any different?
|
| Yes, paying or evaluating programmers by lines of code is going
| to lead to misaligned incentives. However, I'm not convinced the
| dynamic is any worse than for prose. Bill Atkinson spent a week
| removing extraneous code from QuickDraw; an author might spend a
| week cutting extraneous subplots from a novel. Word count is
| still a useful metric for the author.
|
| Perhaps the difference is that non-writers tend to be more
| familiar with the writing process than non-programmers are with
| coding. If an author was working on revising a novel, no one
| would ask them how many words they'd written that week.
|
| Or maybe word count measurements are in fact making everyone's
| prose worse and we should do away with them too.
| comfypotato wrote:
| It's my understanding that Tolstoy was paid by the page (or
| something like that based on how many words he wrote). It's an
| interesting analogy to code in that Tolstoy's writing is
| wonderful. His style is delightfully monotonous. It's
| interesting to note that the incentives you're talking about
| don't have to result in _bad_ code just _different_ code (in
| the hands of a good enough programmer).
| markstos wrote:
| I worked at a print newspaper. They have target word counts not
| because it's a great metric because that's literally the amount
| of space they have for article on the page. Same for magazines.
| There is a target number of pages in the issue. Any business
| that publishes in both print and online still has that
| constraint.
|
| Online daily newsletters are designed to take so many minutes
| to read, which is calculated directly from the word count. So
| word counts often have utility.
|
| Coding sometimes has space and memory constraints but often it
| works best to optimize for maintainable code, which might be
| shorter or longer depending on the case.
| [deleted]
| BlargMcLarg wrote:
| The code is different in the sense that good abstractions and
| function definitions, when not used in excess, will severely
| cut down the amount of lines. However, given the same amount of
| time and not a lot of time spent on thinking about
| abstractions, odds are they will end up with fairly similar LoC
| counts. Just developer A will have written more features,
| whereas developer B will have done the same thing over and
| over, without having the same features.
|
| That's where your example of writers should take hold too: good
| writers stop being paid by the word and start being paid by
| number of sales. The same should be done with devs.
|
| That said, the entire thing gets tossed out of the window when
| considering significant portions of developers will overthink
| abstractions, fiercely hold onto overabstractions (which end up
| bloating LoC), have discussions with each other ad nauseam,
| slow down code reviews over petty differences, and more.
| skrtskrt wrote:
| Also if you write an abstraction then your teammates use it,
| the measurement on either you or your teammates or both is
| going to be skewed whether you're going for high or low LoC.
|
| If
| badsectoracula wrote:
| > And yet, many writers are still paid by the word, and many
| book contracts still specify target page counts.
|
| That doesn't really mean anything, after all some managers
| still judge productivity by LoC. They both can be bad.
|
| And at least IMO, using word counts for books is giving very
| wrong incentives. I've stopped reading non-fiction books
| because absolutely every single one i've tried to read over the
| years _always_ *ALWAYS* gets way too wordy, spending entire
| chapters in what one could fit in a blog post. And i 'm writing
| that as someone who also tends to err on the "wordy" side -
| both when writing and when reading (i.e. when in doubt, i think
| it is better to write more). But books tend to overdo it to
| fill those contract pagecounts.
| Wowfunhappy wrote:
| Right, and that's why I said at the end of my post, it may
| just be that length is a bad metric in both cases.
|
| However, I'd posit that if you went into a forum of
| professional writers and asked how they felt about word count
| measurements, they'd be a lot more divided than we are
| regarding lines of code. Or, to pick another example,
| NaNoWriMo seems to be pretty popular among aspiring authors,
| and that's _all about_ the wordcount. Maybe it shouldn 't be
| --or maybe there's something we're missing.
|
| For example: it may be the case that lines of code is a
| useful goal during certain phases of a project--maybe while
| prototyping, for example. Just like how a target word count
| is useful when writing a rough draft, but obviously stupid
| while revising a draft.
|
| Although, an author might set a goal to get _below_ a certain
| word count during the revision phase--and that again might be
| a useful target for programmers refactoring code.
| wirrbel wrote:
| You lost me at "Allow me to play devil's advocate for a moment"
| njharman wrote:
| I would argue the bloated 10+ book series that fantasy and sci-
| fi have devolved into is the exact bad outcome of LoC or word
| count metrics.
| Retric wrote:
| Customers pay by the word, as in the publisher prefers
| someone buys a 10 book series vs a 3 book series.
|
| However, people don't buy programs like that. If Madden 2023
| has 10x as many LOC as Madden 2022 the price doesn't change.
| hprotagonist wrote:
| My favorite PRs of late have come in at numbers like +280/-1257.
| (I replaced a lot of janky flask handholding with the equivalent
| fastapi machinery, to much joy.)
| hinkley wrote:
| Gave myself an RSI writing -500 LOC in vi. Only discovered the
| block indent instruction partway through.
|
| It was copypasta of a bad n2 idiom for collision detection
| between two search criteria. So first I had to replace it all
| with a function, then change the function. Made the app actually
| usable though.
| [deleted]
| kbenson wrote:
| I imagine this is in response to the rumors that Twitter
| employees had to print out the code changes they did in the last
| month to justify their jobs. This, and stories like it, are what
| I thought of when I heard that.
| samatman wrote:
| Has there been any definitive reporting on this?
|
| What I remember reading on Twitter at the time, was that devs
| were expected to print out about fifty pages of diffs relevant
| to the last six months of their work. Rather than printing out
| all changes from the last month.
|
| The printout part makes me question the idea that code was
| being counted. That part is easy to do with tools which Twitter
| undoubtedly has.
|
| I've never worked a job where I couldn't print out 50 pages of
| diffs for six months, although I have the sort of temperament
| where I'd probably sandbag or quit if asked to.
|
| There's little point in speculating on this until a clear
| picture emerges. I can't imagine a winnowing process for a new
| takeover that didn't involve some kind of portfolio justifying
| the worker's salary. Not at Twitter, which was notoriously
| overstaffed and had a reputation for rest-and-vest.
| YZF wrote:
| They should print out the diff ;)
| jspash wrote:
| Or bump up the font, increase the margins and leading. It
| worked for my high-school book reports!
|
| 4 pages? No problem.
| andirk wrote:
| How about get to know your team and it becomes very obvious who
| is more productive.
|
| If you need a metric for, say, large teams, how about: # PRs x
| level of effort, + bonus points for being useful outside of code.
|
| Great engineers are like a 5'10" [attractiveness redacted] [hair
| color redacted] [gender redacted]; it's very obvious, isnt it??
___________________________________________________________________
(page generated 2022-11-05 23:00 UTC)