[HN Gopher] -2000 Lines of Code (2007)
___________________________________________________________________
-2000 Lines of Code (2007)
Author : colinprince
Score : 215 points
Date : 2024-03-23 05:19 UTC (17 hours ago)
(HTM) web link (www.folklore.org)
(TXT) w3m dump (www.folklore.org)
| 1letterunixname wrote:
| +KLoC is a terrible KPI that optimizes for complexity, waste, and
| artificial job security-seeking behaviors.
| ck45 wrote:
| It's Goodhart's law: "When a measure becomes a target, it
| ceases to be a good measure"
| enva2712 wrote:
| I'd interperet the cease qualifier in goodhart's law to
| require the measure to be good in the first place, but I
| think SLOC is a negative indicator regardless of whether it's
| a target
|
| I think there are parallels between Deutsch's ideas about
| explanation and the concept of coincident vs inherent
| complexity
| Almondsetat wrote:
| This also goes for Goodhart's law itself
| arrowsmith wrote:
| https://xkcd.com/2899/
| samatman wrote:
| This is indeed funny, but the 'tribune' role of finding
| bad law/process and advocating for its removal is missing
| from most government, corporate or otherwise, and that's
| bad.
|
| It is in fact the same phenomenon as treating +SLOC as a
| proxy for productivity. When everyone is rewarded for
| adding process, but it isn't anyone's job to remove it, a
| system inevitably ends up with too much process.
| arrowsmith wrote:
| Lines of code is a bad measure even if it's not a target.
| threatripper wrote:
| But they ARE a KPI that is easy to understand and measure.
| _ZeD_ wrote:
| they are not a KPI in the first place. loc is not a
| performance index of any kind.
| bertylicious wrote:
| Edited: wrong parent
| solumunus wrote:
| How can it be a KPI if it doesn't measure performance?
| threatripper wrote:
| If you type faster you get more LOC. If you slack off all
| day you get zero.
|
| It does measure something, not necessary something useful
| but zero LOC indicates trouble.
| drchickensalad wrote:
| That's such a limited view which creates terrible
| incentives.
|
| If you work insanely hard solving a problem, you often
| end up with 0 loc + an incredible amount of
| understanding. If you slack off all day then spend an
| hour writing a bunch of sloppy code, you have way more
| loc than someone who worked all day to refine some simple
| clear performant code (which is then read 500 times
| before it's changed, hence the time is earned back with
| interest).
|
| These scenarios don't have to happen for the disincentive
| to still affect the work people do; there's a continuous
| problem from the baseline to these extremes.
| datavirtue wrote:
| I'm on day two of an analysis, zero code written. I don't
| know what, if anything, needs written. If I had to pound
| out something to keep from being zero it would be fraud.
| samatman wrote:
| The Platonic ideal of the perfect manager is still going
| to want to know what's going on when a report isn't
| checking in commits. I vigorously agree that software
| quality requires that developers be free to take time to
| analyze, plan, or just think things through, but zero
| code days can also indicate a blocker or a performance
| issue, and a manager should be helping with those.
| convolvatron wrote:
| the platonic ideal of a perfect manager grows a culture
| where if people have issues with other developers, or the
| organization, or is just stuck, they naturally reach out
| to other people. I fail to understand this model where
| 'blockers' are some kind of hidden disease that a manger
| needs to actively ferret out. in fact, in healthy
| organizations I've worked in..the whole notion of a
| blocker doesn't really exist. its more like 'I talked to
| this person and we decided that they should merge an
| earlier version of their work, because otherwise I'm not
| going to be able to start for another 3 weeks and that
| totally blows our schedule'
|
| and that ideal manager has a much better and
| multidimensional idea of performance over time than
| commit rate.
|
| the platonic ideal of manager isn't some kind of school
| marm whose primary concern is figuring out when people
| are slacking off
| samatman wrote:
| > _the platonic ideal of a perfect manager grows a
| culture where if people have issues with other
| developers, or the organization, or is just stuck, they
| naturally reach out to other people._
|
| Agreed, and this includes managers reaching out to their
| reports.
|
| > _I fail to understand this model where 'blockers' are
| some kind of hidden disease that a manger needs to
| actively ferret out._
|
| You're imputing an attitude to me which I neither hold
| nor intended to convey.
|
| > _in healthy organizations I 've worked in..the whole
| notion of a blocker doesn't really exist._
|
| Weird. The idea that a step in a process can't be
| completed before another step seems bedrock to me. It's
| always good to eliminate these dependencies when one can,
| but that isn't always possible.
|
| > _the platonic ideal of manager isn 't some kind of
| school marm whose primary concern is figuring out when
| people are slacking off_
|
| Considering that should be obvious, since an ideal
| doesn't have negative qualities, I'm forced to conclude
| you're responding to a bunch of things I didn't say.
| rsynnott wrote:
| The most valuable work I ever did, at least in monetary
| terms, involved zero lines of code (or certainly
| mergeable lines of code) for significant amounts of time
| while I figured out if the thing was possible, desirable,
| tested it, advocated for it... My manager was fine with
| this.
|
| I've got to admit, I found this kind of _frustrating_ at
| the time, but if I'd insisted on writing something,
| anything, from the get-go, it would have been a complete
| disaster, and no-one would have thanked me for it.
| HarHarVeryFunny wrote:
| > zero LOC indicates trouble.
|
| It may indicate an employee with nothing to do, but in
| that situation would you prefer the employee did nothing,
| or started destroying the code base by adding KLOC of
| garbage to keep their manager happy and unsuspecting ?
| rsynnott wrote:
| KPI stands for "Key Performance Indicator". Lines of code are
| clearly not this; they don't indicate anything about
| performance one way or another.
|
| (Now, mind you, I'm sure that lots of other 'KPIs' are
| nothing of the sort, either.)
| michaelcampbell wrote:
| For you, maybe; but to your parentposter's point, it is
| measured not because it is useful to the overall org, but
| because it is easy to measure. In that sense, it's a great
| KPI, when the measurer (presumably some middle management)
| considers it an indicator of performance.
|
| It's just that you and they define "performance"
| differently. It's perverse incentives all the way down (or,
| perhaps, up).
| rsynnott wrote:
| I mean, sure, if you have a sufficiently bonkers view on
| performance metrics, then, say, index finger diameter
| could be a performance metric, but in terms of things
| which could actually be seen by any reasonable person as
| a KPI, lines of code ain't one.
| eloisant wrote:
| It's obvious today to everyone, unfortunately we replaced that
| by KPI that are no better.
| chii wrote:
| > they stopped asking Bill to fill out the form
|
| which is only possible because he's so important.
|
| imagine doing this as a stack-ranked IC in an org like AWS.
|
| The old days of a software as an artisanal craft is long over
| imho.
| quelltext wrote:
| I'm by no means important in my org but when something appears
| like a shitty idea I will raise that (like other ICs around me)
| and more often than not it works out fine. I'll agree to give
| something a shot but if it doesn't work it doesn't work and my
| managers so far have all realized that a bit into the trial
| period.
|
| Reading comments like yours, I guess I should value my work
| environment more.
| bickeringyokel wrote:
| The question is really more do they actually act on the
| feedback on a regular basis?
| xiphias2 wrote:
| If you want to see an extrema of people being afraid to speak
| up, just look at the Gemini image examples in a company that
| in theory encourages people to speak up. There are always
| topics that are exceptions.
| pbhjpbhj wrote:
| If you're OOTL on Google Gemini ML-based content creator
| then https://blog.google/products/gemini/gemini-image-
| generation-... is a pretty good summary.
|
| Ostensibly it appeared to be tuned to be racist.
|
| Maybe Google encourages people to speak up but also has a
| culture of racism?
| eloisant wrote:
| It's not about speaking up on a shitty idea, it's about not
| playing the game on a tool used to measure employee
| performance. That's a big difference.
|
| Especially because here we're talking about someone whose
| performance and contributions were very clear to everyone.
| Otherwise, he might have been seen like an underperformer by
| managers.
| zelphirkalt wrote:
| I think you are very fortunate then. The number of times I
| have raised concerns and my warnings have been ignored ...
| Even when I had direct past learning or experience with the
| thing they want to do, I can no longer change their mind.
| rsynnott wrote:
| Yeah, honestly over nearly 20 years of working in this
| industry, I'm not sure that I've ever worked anywhere where
| there'd be significant management pushback on something like
| this. Now, granted, I've mostly worked in small companies,
| and one rather selective largish companies; maybe things
| really are much worse in the truly huge companies.
| edent wrote:
| And now you understand why programmers need to be part of a
| Trade Union.
|
| Protection from retaliation and group negotiation on working
| conditions are brilliant for people who aren't as "important"
| as Bill.
| kjksf wrote:
| And the probability of creating a Macintosh in a union shop
| is zero.
|
| Abusive boss, normalized unpaid overtime, compensation based
| heavily on stock options, pay and promotions being based on
| merit and not on seniority and time spent in a company.
| kbolino wrote:
| Unions have their own politics. The good ones will do this.
| The bad ones will make your life a living hell for causing
| trouble. Whether it's worth it to unionize will be
| situational.
| Cheer2171 wrote:
| > The old days of a software as an artisanal craft is long over
| imho.
|
| In corporate or government software work, sure. But there are
| no guilds anywhere in those organizations... unless you count
| the upper executives.
|
| You might not get paid for it, but the artisanal craft of
| software is alive and well in free and open source software
| around the world. Tons of those projects get posted to HN. An
| app can be a home cooked meal and all that jazz. Lots of open
| source has been corportized too, but many are closer to an
| artisanal craft guild than modern corporate software work.
|
| And if it is your startup, you can write code however you want.
| samatman wrote:
| For better and for worse, it's been decades since filling out a
| form was a necessary or even useful part of tracking this sort
| of thing. The widespread use of revision control and ticketing
| systems means that management has that data at their fingertips
| whenever they want it.
|
| Sometimes that's good, sometimes it isn't. But I think we can
| count relieving the developers of the drudgery of form-filling
| as an unalloyed good.
| knallfrosch wrote:
| AWS has 136,000 employees. Of course they're mired in
| management and processes.
|
| Simply work for a smaller company..
| bickeringyokel wrote:
| The cynic in me believes managers actually don't want good
| metrics because then they have evidence of their bad leadership.
| hinkley wrote:
| It's why they love claiming "culture fit" on anyone older than
| them. 28 year old managers feeling threatened by 30 year old
| employees.
| bickeringyokel wrote:
| Anecdotally, I have not found much correlation between age
| and management style. I have had bad managers of all ages!
|
| I have had one good manager though, and it's pretty obvious
| what made them great. First is they listen to what problems
| you have and actually help you do your best work. Secondly,
| they protect you from the other bad leaders at the company.
| Thirdly, they work too hard.
| richrichie wrote:
| Work _too_ hard?
| mangamadaiyan wrote:
| GP probably meant to type "they too work hard", I guess?
| pooper wrote:
| Maybe that is a relative thing? As in the norm is bad
| managers delegating everything to a fault, so a good
| manager by comparison works too hard?
|
| Or maybe it is an availability thing? My personal
| experience is I'm much more motivated to work If my
| manager is highly available from early morning to late
| evening.
| pietroppeter wrote:
| I guess somehow remarks about lines of code being (mostly)
| meaningless to measure programmers' productivity feels related to
| the extent of the impact AI will have on software engineering.
| praptak wrote:
| The largest impact is sometimes asking simple questions (how are
| you going to handle X?) which leads to _not_ building something.
| When this something hasn 't ever had a chance to work, you saved
| the whole cost of trying to build it.
|
| This is not only impossible to measure as a numerical metric but
| also makes you enemies. Kudos to those who dare to do that
| anyway.
| anonzzzies wrote:
| > The largest impact is sometimes asking simple questions (how
| are you going to handle X?) which leads to not building
| something.
|
| Which is why I teach new people to have that loop in your head
| and not start pounding the keyboard at high velocity. The
| people who find programming to be akin to fast typing show very
| interesting equivalence with LLMs; fully
| write/remove/write/remove etc of not very well written code.
| atoav wrote:
| Mhh for me it is always a combination of the two. I like
| making a good high level plan, but for certain problems it is
| better to make the plan as you go, because you can't fully
| understand the shape of the problem and the potential
| solutions as you start. Sure maybe that means your first code
| sucks and is a prototype that should be replaced, but if you
| are aware of that and don't pretend otherwise I don't see why
| this wouldn't be okay.
| hinkley wrote:
| Gave myself RSI deleting <600 LOC with vi.
|
| On the plus side I replaced an O(n2) algorithm with a faster one
| in the very next commit. Needed to get rid of the ninety copies
| of the same bad idiom first.
| hsjsbeebue wrote:
| 600dd:w shouldn't cause RSI ;)
| hinkley wrote:
| It was five to six lines of code repeated in half a dozen
| spots in a dozen files, with different variable names, and
| different arguments. And I wasn't deleting them, I was
| replacing them with the same function call.
| aidos wrote:
| That's got "macro" written all over it.
| jraph wrote:
| That's a sed /d of course. Or a "Replace all in folder"
| in any decent code editor.
|
| Or a sufficiently efficient "extract to method" on a
| decent IDE, that notices the different occurrences even
| with renamed variables.
|
| Unless those lines of code were subtly edited all over
| the place and needed careful and subtly different replace
| for each occurrence, or at last review because that's
| what's truly evil with duplicated code. It's forks that
| diverged to maintain N times in your codebase.
| selcuka wrote:
| > Gave myself RSI deleting <600 LOC with vi.
|
| Why? Didn't you know the shortcut `d600d`? /s
| mehdix wrote:
| I was giving myself RSI by deleting <12000 lines of copied
| comments (only misleading noise, explaining _what_ was
| happening) and <4000 LOC (replaced with a 120 LOC in a single
| fn) when I reverted to using regex while sanitizing a badly
| bloated codebase.
|
| Can feel you right there.
| veidelis wrote:
| Not much of an achievement, but I once deleted a 45k line Jest
| snapshot test for a React component that basically asserted
| that a div is rendered.
| prettyStandard wrote:
| Maybe you are being sarcastic...
|
| Or you've completely missed the point of the article/story.
| The point is lines of code are almost meaningless. In this
| story the person saved 2k lines of code by rewriting a
| rendering engine, and use somehow think that's less than
| deleting a 45 k line jest snapshot.
| stuartd wrote:
| "Not much of an achievement, but" here refers to the
| commenter's action, not the one in the article
| veidelis wrote:
| Sorry, if it somehow sounded that my example is somehow
| more than what was mentioned in the article. Absolutely
| not. I think that my example also very well demonstrates
| that lines of code (even that isn't really "code") isn't
| not a good way of measuring productivity etc. My example
| could be considered as an example of how a code review
| didn't "do it's job" for what might have been a newbies
| mistake. But I also think that code reviewers cannot be
| blamed for every bad piece of code that gets through
| (context matters).
| joaquincabezas wrote:
| this keeps coming... recently there's been a bit of debate
| between Milvus and Qdrant on this topic:
| https://www.linkedin.com/posts/yujiantang_how-can-you-judge-...
| khazhoux wrote:
| Cartoonish anecdotes like this take away from that actual value
| that LOC can provide to management, when employed judiciously as
| one data point among many.
|
| It is very informative for managers to take a periodic look at
| the number/frequency of commits from each engineer and their
| size, and from there dive into each commit and explore the
| denseness of the code, the cyclomatic complexity, and the overall
| nature of the commits.
|
| This can reveal potential problem areas for the manager to
| investigate with the engineer. You might find that the engineer
| has very few, very small commits compared to their peers, and
| then upon looking at the actual code you may find that the code
| seems rather trivial. This would warrant a conversation. Why have
| they reported at every standup the last six months that they're
| stuck behind very tricky problems when the commit history shows
| only a couple of seemingly simple changes? Maybe the problem
| really was tricky, but maybe the engineer is struggling and
| doesn't realize it. So let's find out.
|
| So while no one should be reduced to a simplistic LOC metric, and
| recognizing that more code can mean more bloat, we can't pretend
| that the amount of code that a developer writes is devoid of any
| meaning, as if it were just a random number.
| lakpan wrote:
| Sorry but your argument makes no sense. The 10LOC/day guy is
| not to be singled out from the 1000LOC/day people because 1000
| LOC could be just as trivial; 1LOC could have taken hours to
| discover.
| xandrius wrote:
| Exactly! I've myself spent days investigating an issue only
| happening on a specific Android device (but used by an
| important client) only to find that the solution was
| something along the lines of using "opacity: 0.1" instead of
| 0.
|
| That bug was left unfixed for months but now it's solved.
| Should I have received a talk because of that?
|
| (Of course the commit would have had at least 10 LOC more,
| explaining the reasons and providing references to future
| devs/self)
| khazhoux wrote:
| > Should I have received a talk because of that?
|
| Of course not.
|
| But, if your commit history for last 6 months is just one
| or two of those one-line changes a month, that might hint
| that there's a problem.
| mdp2021 wrote:
| That makes your point clear, but then what you are
| looking for is not a scalar value (that may be for
| instance be subject to a proportional judgement) but a
| fuzzy threshold.
| eviks wrote:
| Might that hint that the problem that is there is that
| the metric is bad?
| khazhoux wrote:
| So if you managed a team, and when you look at commit
| histories you notice that one person has <1 commit a
| month and you look at the commits and they're trivial...
| you would disregard any concerns?
| jen20 wrote:
| I would wonder how it got to the second month, certainly
| - getting to the point where this kind of post-hoc
| analysis can actually be done is a serious failing of
| management.
| xandrius wrote:
| The answer is still "it depends", I would imagine that
| issues would arise well before you had to look at their
| commit history.
|
| I believe that if you are a good manager, you would just
| need to look at what tickets get done during the sprint
| and that's it. If you complete your tickets and pass
| QA/UAT in 10 LOC, so be it. There is no need to
| micromanage.
| Moru wrote:
| This is exactly why KLoC is not a good measurement. If
| you know about this, you will make sure you match
| everyone else by embellishing your line count with
| comments, copy and rename functions or extra deep
| nesting. The manager will still not know anything without
| looking at everyones code.
| khazhoux wrote:
| A good manager should look at everyone's code.
|
| A good manager should recognize that if a developer does
| nothing but annotate code with comments, and that's not
| what they're expected to be doing, there's a problem.
| Moru wrote:
| Ofcourse, but if the manager is using the KLoC to decide
| who to look at, that won't happen.
| rsynnott wrote:
| I mean, seems highly role-dependent. If, in practice,
| your role is to investigate and fix very difficult
| problems, that's precisely the sort of commit history one
| might expect.
| khazhoux wrote:
| Right. One data point among many. And managers should be
| looking at everyone's code, not just the low LOC ones.
|
| But there are people (I've seen this frequently) who
| constantly represent their work as having been "much more
| difficult than expected" but then you discover that they
| actually are struggling with what should be easy tasks, and
| looking at code (complexity and volume) is a data point. For
| me, more often than not, it serves as a _confirmation_ of a
| problem I've started to suspect.
| eviks wrote:
| confirmation bias indeed works that way more often than
| not: it confirms what you already believe
| khazhoux wrote:
| I'm confused which part of this is so off-putting.
|
| Joe is always the one in every standup saying the thing
| he's working isn't done yet because he's wrestling "one
| last tough bug." As a manager, you wonder if the
| technical problems are really that tough or if Joe is
| just struggling. Let's look at the commit history...
| yeah, something is off here, Joe has 1/10th the commits
| of his peers and they really don't seem more complex in
| any way, but look rather trivial. Time to talk to Joe and
| look at these commits together and see what's going on.
|
| Is that really such a troubling proposition?
| eviks wrote:
| So troubling that you can't propose it cleanly: if you've
| already defined that "they really don't seem more complex
| in any way, but look rather trivial", why would you need
| to count? (another troubling sign is going for the order
| of magnitude assessments, and another minor point: you've
| mistakenly replaced volume of code with # of commits)
| jen20 wrote:
| So why wasn't the response after day 1 of the "tough bug"
| something like "hey, why don't you pair with X to get to
| the bottom of it?"?
| samatman wrote:
| If you declare by fiat that every confirmation is
| confirmation bias, you've made knowledge impossible.
| supriyo-biswas wrote:
| I wonder what the grandparent would think about a few
| LOC/month, there were a few rather gnarly performance issues
| in the codebase at my work for which the fix was usually a
| one or two liner, but that took an inordinate amount of
| research to even know where to start looking.
|
| I guess I should be grateful for having a workplace that has
| sufficient understanding for the effort it takes to debug
| such issues.
| khazhoux wrote:
| Yes, but I'm guessing your commit history over the last
| year is not just 1/2-liners once a month, right?
| octopusRex wrote:
| Do you really expect most managers, if any, would do this?
| khazhoux wrote:
| No, probably not. And most don't try. My point is that --with
| proper context and thoughtful analysis-- it is data that can
| be useful.
| peteradio wrote:
| At the end of the day nothing about the number of commits
| was used in your thoughtful analysis, it was only the
| contents of the commits which you attribute any value.
| khazhoux wrote:
| Yes and no. Certainly I know lots of great developers who
| prefer to commit work frequently and incrementally,
| others who do slower bigger changes. But I don't think I
| know any engineers who can create a substantial amount of
| software with only infrequently and tiny changes.
|
| I encourage you to look at the code produced by whoever
| you think is the top engineer in your team or company
| (and I'm talking only about the engineers whose job is
| still primarily hands-on coding, versus
| advising/mentoring/architecting etc). Now look at the
| code by that one person who you _know_ isn 't pulling
| their weight and who you think isn't getting much done.
| I'll wager that your top engineer is pumping out a ton of
| strong code, and the other one is a trickle.
| Ultimatt wrote:
| The main issue is the majority of managers arent especially
| qualified to make a judgement of the code itself which makes
| the metric spurious at best. Lines changed is at least a better
| version than lines added. But it is fairly devoid of meaning
| removing ten lines can be extremely hard and impactful compared
| to adding 1000 lines of deeply nested ifs written poorly. Lines
| changed multiplied by number of files touched is possibly
| better too.
| mavhc wrote:
| Any generic measurement of productivity is a sign that the
| manager is incompetent.
|
| If you're a manager and can't tell what your employees are
| doing, you're a terrible manager. Same reason they hate
| people working from home, they can't actually tell if
| someone's a good employee, they have no clue whether anyone
| is good at their job because they don't understand their job
| khazhoux wrote:
| My entire premise is:
|
| 1) A good manager needs to look at code to see what
| employees are actually doing. They can't just rely on the
| employees' verbal description.
|
| 2) One (correlated though not guaranteed) indicator that an
| engineer is struggling is when they are producing much less
| code than their peers or compared to any natural
| expectation of the role. Yes of course it's 100% that some
| bugs are super tricky and take a long time to find the
| magical one-liner fix. But statistically those are not
| common.
|
| This is premised also on my belief that every engineer
| manager should be a _very strong_ engineer themselves. This
| is common at most of the big tech companies.
| mdp2021 wrote:
| > _we can 't pretend that the amount of code that a developer
| writes is devoid of any meaning_
|
| The scalar of <<amount of code that a developer writes>> _is_
| <<devoid of any meaning>> outside frameworks of streamlining of
| such code (which would themselves not be a good idea, as you
| would in fact actually have classes of code, to be judged
| differently). The submitted specifies it was a case of a simple
| scalar field in a form.
|
| Your argument is of course valid, but your conclusion
| disregards it. Outside a defined framework of quality
| adherence, the <<amount of code>> is <<a random number>>.
|
| The interesting part is all in the productivity (bulk of
| quality). That is the area that should be investigated - in
| both discussion and assessment.
|
| And clearly, "amount of code produced" is a bad incentive,
| against quality. Aaaalways take care and beware of incentives.
| pflenker wrote:
| LOC as a datapoint provide no value that a manager couldn't get
| quicker and with less ambiguity via other sources. For example,
| identifying engineers struggling for a month on a topic, as you
| described, can be uncovered way earlier by replacing a
| reporting-Like ,,standup" with collaborative structures that
| help the team, and the manager, understand progress and
| potential blockers. LOC are lagging way behind on issues like
| these and are devoid of any meaning in isolation. I know your
| counter argument here is ,,one data point among many", but mine
| is: if your other data points are solid, LOC do not add any
| value.
| khazhoux wrote:
| With the exception of engineers whose role is strictly
| advisory, architectural, etc, for most engineers the direct
| literal expression of their work is the code that they
| commit. Not the design document, not the ideas in their head,
| but the code in the repo. Managers should be looking at this
| code in their evaluation of everyone's work. Someone with an
| unusually-small amount of code shouldn't be "punished" but it
| is something that should be noticed and examined.
| pflenker wrote:
| That is the equivalent of saying that the direct expression
| of a musician's work are the sounds they produce and
| therefore they should be heard in isolation. But as much as
| an orchestra produces symphonies as a group, development
| teams produce software as a group. This output matters and
| should be looked at, the individual code contributions to
| that output matter less and looking at them in isolation
| doesn't provide insights that looking at the team's output
| in terms of working software, bugs, incidents and more
| wouldn't.
|
| A manager looking at the individual LOC contributions is
| looking into the wrong direction.
| ZaoLahma wrote:
| There was a bug in an embedded system I worked on that several
| engineers, software as well as hardware, spent months
| troubleshooting.
|
| I eventually got called in and fixed it with a while loop and
| one function call inside of that loop. 4 lines in total,
| counting the brackets.
|
| A very trivial change if you didn't know why it was there, what
| impact it had on the system or how much it would have continued
| to cost in engineering hours if I hadn't figured out what went
| wrong, why it went wrong and how to fix it.
|
| I've spent a good chunk of my 15 years as a software developer
| as a pure "bug killer" and then you don't really get to write
| that many lines of code, but the impact per line is big.
| khazhoux wrote:
| Agree fully. Yours isn't the case I'm talking about. I'm
| talking about the people that aren't hunting big bugs, aren't
| serving as advisors or architects, aren't deleting unused
| code, and aren't implementing a significant volume of
| features or functionality, but who instead trickle out a
| small amount of simple code month after month. I claim that
| when inspecting commit histories, a very low LOC or very low
| commit-frequency is something a manager should look into.
| datavirtue wrote:
| All you have to do is read commit messages.
| khazhoux wrote:
| Reading commit messages is a poor substitute for reading
| code.
| ResearchCode wrote:
| > Why have they reported at every standup the last six months
|
| Every what?
| khazhoux wrote:
| Standup. Daily meetings where teams talk about their blockers
| and so forth.
| ResearchCode wrote:
| If six months of daily meetings did not lead anywhere then
| cancel those meetings.
| khazhoux wrote:
| Many teams have short daily gatherings -- especially now
| that so many teams are fully distributed, it's good for
| everyone to come together like that.
|
| But while every team member talks about the difficult
| bugs they're facing, sometimes the actual code tells a
| different story and can reveal that a team member is
| struggling to get working code together in any reasonable
| amount of time.
| ResearchCode wrote:
| It sounds like you could just read their code and the
| meeting was unnecessary. Linux kernel developers are
| distributed but don't do daily status update meetings.
| erinaceousjones wrote:
| heh, I note your recent comment history is you being salty
| about everything you deem "cargo cult agile", and people
| patiently responding to that.
|
| Yes, having a chat between the team for fifteen minutes every
| day is in fact quite useful, believe it or not.
|
| We're not talking about hour long waterfall-y management
| progress review meetings here.
| ResearchCode wrote:
| Daily status updates are not useful. Linux kernel
| developers don't do them. I trust that nothing is stopping
| your engineers from having a chat and that their manager
| doesn't need to schedule their chats for them.
| erinaceousjones wrote:
| You speak in absolutes. What works for me, works for me
| :)
| samatman wrote:
| Cargo-culting someone else's process is a bad way to
| develop good process for your specific team and its
| needs.
|
| You could use the same logic to claim that "issues and
| PRs are not useful" because the Linux devs use a mailing
| list and patches. I think that's obviously absurd, all
| that this example shows is that a mailing list and
| patches can be a useful way to develop programs. It says
| nothing about alternatives at all.
| ResearchCode wrote:
| What specific needs are met by daily status updates?
| Professionals outside of software don't do that. The best
| software projects don't do that. It's very popular in
| CRUD projects led by non-technical middle management with
| trust issues.
| samatman wrote:
| > _Professionals outside of software don 't do that._
|
| How do you know this? Have you done an exhaustive search?
|
| For one example, are you quite certain that no part of
| any military ever does this?
|
| What about every factory?
| ResearchCode wrote:
| You are not answering my question. No, you ask your
| acquaintances who work in law, finance or medicine.
| Neither does academia have any "stand up". What specific
| needs do CRUD software projects have that are met by
| infantilizing daily status reports? What needs for daily
| status reports do these projects have that the Linux
| kernel doesn't?
| khazhoux wrote:
| > What specific needs are met by daily status updates?
|
| You are assuming (1) that standups are status updates,
| and (2) that they are scheduled by manager, and (3) for
| benefit of the manager.
|
| In the last several teams I've managed, it's the crew
| that has encouraged meeting daily, and in the standups
| they are mainly talking to each other. It's where they
| cover hot topics and bugs for the day quickly, with the
| fluidity of spoken conversation instead of Slack, and
| also there's a non-zero amount of friendly casual
| conversation.
|
| Don't force teams to have standups, but also don't assume
| a team won't like it.
| jen20 wrote:
| > Professionals outside of software don't do that.
|
| What, and I mean this in the nicest way possible, the
| everliving fuck are you talking about?
|
| Professionals do this constantly. Go sit in an ER and
| watch the hand off between shifts. Go see any serious
| manufacturing facility and see them review daily
| everything that happened the previous day. Go see an
| effective sales org in action.
|
| The scrumbags may have ruined software, but that
| certainly isn't the world.
|
| You make your not entirely unreasonable points sound like
| the output of a zealot.
| wesselbindt wrote:
| Here's some counterexamples to that idea:
|
| - a bugfix which takes ages to find and ends up being one or
| two lines of locally trivial code
|
| - a senior who spends most of their day unblocking junior devs
| and keeping the team on track: 0 lines of code
|
| - overzealous code formatters: lots of lines of code
|
| - a junior writing an overly complicated mess of a solution to
| a problem that could be solved much more simply: ungodly
| amounts of code
|
| - a developer talking to the client directly and finding out
| that problem that they're trying to solve is already solved by
| the product in a way that the client didn't think of, rather
| than immediately wasting company resources on a feature that's
| ultimately unnecessary (0 lines of code over lots of lines of
| code)
|
| There is 0 correlation, none whatsoever, between lines of code
| committed by a dev and their value they provide to the
| business.
| samatman wrote:
| > _There is 0 correlation, none whatsoever_
|
| This is quite unlikely to be true. No correlation at all?
|
| Especially if we shift to DSLOC rather than +SLOC, I don't
| believe that for a second.
|
| You've made a good case that it's a bad proxy for
| productivity. It is. But there's no need to over-egg the
| pudding.
| khazhoux wrote:
| > a bugfix which takes ages to find and ends up being one or
| two lines of locally trivial code
|
| I once had a junior engineer who took maybe 4-6 weeks to fix
| an intermittent bug in dynamic lib loading. When he finally
| fixed it, the fix was <5 lines of code. But it was obvious
| that (1) the bug was insanely deep and hard to find, and (2)
| he did amazing kick-ass debugging to uncover it deep in Linux
| code. It was great work, and he was one of our top rising
| talents. But that's not the kind of cases that I'm talking
| about.
|
| No, it's instead the engineer who _gives the appearance_ that
| they 're always doing tough work, but then the commit history
| shows that they're simply not. The person who says they're
| implementing a new data structure in the code, but really
| then take a month to replace a list with a dict in python, or
| whatever. This happens.
|
| > a senior who spends most of their day unblocking junior
| devs and keeping the team on track: 0 lines of code
|
| I'm not talking about them at all. I'm talking about people
| who aren't doing mentoring, advising, architecture, forward-
| looking design docs, etc.
|
| > overzealous code formatters: lots of lines of code. A
| junior writing an overly complicated mess of a solution to a
| problem that could be solved much more simply: ungodly
| amounts of code
|
| Yup, this happens. This is also something managers will learn
| by looking at code.
|
| - a developer talking to the client directly and finding out
| that problem that they're trying to solve is already solved
| by the product in a way that the client didn't think of,
| rather than immediately wasting company resources on a
| feature that's ultimately unnecessary (0 lines of code over
| lots of lines of code)
|
| Absolutely. The best way to get more work done is to figure
| out what work you don't have to do.
|
| But if you have an engineer on your team make $200+K/year and
| they're not writing much code, nor writing design docs, nor
| advising other engineers, nor guiding the technical strategy,
| etc... if all the engineer does all day is "not wasting
| company resources" by doing very little whatsoever, you have
| a problem on your hands.
| alan-crowe wrote:
| It is clear that the weight attached to LOC will decline as
| management acquires more directly relevant information. The
| difficult issue is whether there is a _zero lower bound_.
|
| Imagine buying in software, against a specification. A fully
| detailed specification with tests both for logical correctness
| and performance. If there is a choice of vendors, at similar
| prices, one naturally chooses the package with fewer lines of
| code. The weight attached to LOC is negative.
|
| The anecdote is interesting because it invites the following
| speculation. Question: How many extra data points, beyond LOC,
| does one need to manage a software project? Answer: Enough that
| the weight attached to LOC, given optimal use of the other
| information available, is negative.
| convolvatron wrote:
| oh no. you're responsible for a group of skilled and not so
| skilled engineers in a domain that you don't understand. all is
| not lost.
|
| what is your only goal - to maximize your teams contribution to
| the goals of the company. full stop. its not to stack rank your
| employees unless it serves that greater goal.
|
| but you don't understand the domain. oh no. all you can do is
| develop a human relationship with the team. listen to them. you
| can't judge the quality of their work, but they can.
|
| don't ask them to rank each other (I've seen this), but just be
| attentive. after not to much time you can really start to
| understand how people are helping the effort, and how they are
| undermining it. in broad terms, without understanding the gory
| details.
|
| this is the only thing that works. everything else is just
| obfuscation.
| userbinator wrote:
| A corresponding thought-experiment is to consider the results of
| the opposite situation: if a manager read this article, and
| simplemindedly decided to measure by lines of code _removed_
| instead. Would that make things better or worse?
| xandrius wrote:
| Definitely no new features.
|
| If the product is "finished" then it would probably be equal or
| better (otherwise the negative LOC change wouldn't make it to
| prod).
|
| But most products are ever evolving (that's why we have the
| luxury of remaining on the same project for years), so just
| negative contributions will invariably not add anything.
| anonzzzies wrote:
| Easier to be gamed depending on the company and method of
| measuring; let llama dream up code that looks fine, add some
| code so the code has no actual effect, commit, remove at some
| time later. Any measuring of this kind is pretty much useless
| you have solid code review practices in general place (which,
| unlike people here like to believe, is a rarity). But with good
| reviews, underperformance and gaming the system would also be
| caught so you would have less reason to implement metrics like
| this.
| praptak wrote:
| Worse, because codegolfing the entire codebase is undesirable.
| samatman wrote:
| Any line-based metric should be suspect, but 'delta-SLOC' is
| probably the least bad. I would count added lines and removed
| lines separately, so a +50,-150 patch would be 200 DSLOC.
|
| This isn't a good measure of productivity, especially not in
| isolation, but it's a reasonable napkin-math metric of
| _change_. A developer with a high DSLOC count may or may not be
| more productive than a peer who has a week or two of no DSLOC
| at all, depending on what that peer is up to, but the first of
| these is definitely changing the codebase more than the second,
| during the measured time span.
| seadan83 wrote:
| There is I believe a specific context where removal is good
| and others where that is not the right measure
|
| I'm working on some java 8 cide that was written by folks
| still living in java 1.4 land, lots of opportunities there to
| reduce 20 lines into 3 (plus those devs kinda insisted on
| doing things in painful and unnecessary ways). In parallel,
| I'm working on a Greenfield project. Even on the Greenfield,
| there are times when negative code added is good. Not all
| programmer activities are equal
|
| It's like measuring gas consumption during emergency braking,
| during acceleration, and during normal highway cruising.
| Sometimes it firs, or kinda fits, other times it's just the
| wrong metric. Programming is not a homogeneous activity
| samatman wrote:
| I think we agree with each other? Or mostly so.
|
| DSLOC is just a metric, and what it measures is change to
| the codebase. Yes, some changes are very important, and
| others nearly trivial, so it's quantitive because a
| qualitative metric is a contradiction.
|
| It certainly means different things in different contexts,
| if it's even meaningful at all. My claim is that +SLOC is
| entirely meaningless outside of the tautology that it
| measures what it is, where DSLOC is in fact informative
| about change to the software, albeit not perfectly so.
| seadan83 wrote:
| I believe we would agree, yes.
|
| My hope is to convey more texture here, that programming
| is more than just one thing. EG: "Today I was mostly
| debugging". That could have its own measures. I think in
| large part the measures of programming productivity are
| often too reductive, the measure is incomplete or tries
| to measure "programming" rather than its _many_ distinct
| sub-activities.
| seadan83 wrote:
| Cue the perl one line challenges.
|
| Metrics that are team level dashboards and not shared outside
| of the team are different from pay and promotion incentivized
| metrics. The same metric can have very different behavioral
| outcomes between the two scenarios
| Terr_ wrote:
| Marginally worse, but not as bad as you'd think, because the
| industry _already_ has similar shortsighted impulses in that
| direction.
|
| For example, the perennial idea of replacing all the software
| engineers and their arcane code-text with product-managers
| drawing some special diagrams or flowcharts for "low"/"no"-code
| results.
| hsjsbeebue wrote:
| The moral: even if you are smart as Einstein you are still an
| employee and need to do employee things.
| datavirtue wrote:
| If Einstein was pressured by metrics we would have never heard
| of him.
| michaelcampbell wrote:
| I suspect he was... as a patent clerk. And that may be why we
| never heard of him THEN.
| octopusRex wrote:
| Microsoft and IBM Lines of code clash
|
| >In the PBS TV series based on Bob Cringely's Accidental Empires,
| there is a sequence where Steve Ballmer describes the experience
| of co-developing OS/2 with IBM, how the whole thing became a
| fantastic clash of corporate culture, with Microsoft having the
| small-company attitude of getting things done, and IBM being
| focused on internal measures primarily KLoCs, that is thousands
| of lines of code as a measure of programmer productivity. "All
| they cared about," raves Ballmer, "was KLoCs and KLoCs and
| KLoCs." IBM, apparently, did not care whether the code was any
| good as long as there was a lot of it.
|
| https://ubiquity.acm.org/article.cfm?id=1022357
| exitb wrote:
| For a bit of context, the TV series this refers to is called
| ,,Triumph of the Nerds" and it's a great watch, even today
| (maybe ever more so?).
| sourcecodeplz wrote:
| Found it on youtube:
| https://www.youtube.com/watch?v=toSRmKKiosQ
| patrickmay wrote:
| Not just IBM. A few years back I worked on a large project with
| one of the big international consulting companies as the prime
| contractor. They threw a party for the whole team when the
| codebase hit one million lines of code.
|
| Those of us who knew better treated the "celebration" as a
| wake.
| pixl97 wrote:
| It's terrifying working around fintec and seeing how many
| 20MLOC monoliths are laying around and the code quality
| issues that crop up in them.
| helpmefindpurp wrote:
| This is cope. those applications are there because they
| work. Mistakes in "20M LOC monoliths" are exceedingly rare
| in the financial world. Look how bad "hipster" software is
| in comparison! Billions in profit means billions in quality
| SillyUsername wrote:
| Bill Atkinson, of Atkinson Dither fame.
| https://beyondloom.com/blog/dither.html
| jameshart wrote:
| Bill Atkinson wrote QuickDraw (the graphics libraries that
| underpinned the Lisa and Mac UI), and MacPaint, and HyperCard.
|
| Along the way he kept having to both invent new ways for user
| interfaces to work, and new ways to write software to solve for
| them. There's a kind of synergy that emerged out of the fact
| that he was optimizing both for 'can be done quickly in the
| hardware available on the Mac', and 'provides a great user
| experience', which means that his fingerprints are all over the
| aesthetic of the old black and white Mac. That dither style is
| another example of that kind of marriage of algorithmic genius
| and aesthetic sensibility.
|
| And it shows up in things like the 'marching ants' selection
| boundary (https://en.wikipedia.org/wiki/Marching_ants). Or the
| way lots of user feedback in the classic Mac UI comes in the
| form of inverting pixels (text selection, menu highlighting,
| the way buttons appear during a mouse-down, the boundary of a
| window while it's being dragged), because drawing over
| something in XOR mode was a great way to generate that effect.
| The way he approached putting these tools together in QuickDraw
| also had the effect of things like his famous conversation with
| Steve Jobs about rounded rectangles
| (https://www.folklore.org/Round_Rects_Are_Everywhere.html)
| manifesting as it being as easy to draw a rounded rectangle as
| a square one in QuickDraw, which led to them showing up
| everywhere in the operating system.
|
| The success of the Mac UI was not just that it looked good; it
| was in large parts that Bill Atkinson made a really cleaver,
| small set of tools that made making things that looked good
| easy to make.
|
| Susan Kare's amazing icons wouldn't be nearly as fondly
| remembered if Bill hadn't built the tools that made it easy to
| drop 32x32 pixel masked bitmaps into the UI and invert them
| when you clicked on them.
| Taniwha wrote:
| The real story here is that sometimes you start a project and
| don't really know exactly where you're going, as you get into it
| you start to understand both the problem and the answer you want
| much better - and then yes, you can rip a chunk out and replace
| it with something smaller and better
|
| And don't forget, these guys had to fit everything, including
| those -2000 lines of code (assembler code) into 64kbytes of ROM -
| there was intense pressure to make stuff smaller
| mananaysiempre wrote:
| QuickDraw is mostly written in Pascal with critical loops in
| assembly[1,2]. I'm also not sure if it's in actually in ROM or
| on the boot floppy. (Incidentally, Wikipedia tells me the
| Lisa's ROM was 16K.)
|
| [1] https://computerhistory.org/blog/the-lisa-apples-most-
| influe...
|
| [2] https://computerhistory.org/blog/macpaint-and-quickdraw-
| sour...
| JoeAltmaier wrote:
| Same nonsense at Convergent in the early days. Jim Frandeen
| worked on tightening up the OS, saved like 10% memory footprint.
| Likewise, a negative code count. That manager actually quit.
|
| My own experience was changing a 10K line module with a template
| in one page. Put some angle-brackets in about 100 references
| which left a net -9900 LOC
| zac23or wrote:
| Counting lines of code as a production metric is very stupid. I
| remember solving an unsolvable 20 years old bug with a line of
| code, another 3 years old with a order by. How to measure the
| impact of a line of code? And in my experience, bad programmers
| write a lot more code...
|
| I will never forget the story[1] of a Microsoft developer
| rewriting a piece of IBM code that had 33 thousand characters,
| after rewrite ... 220. This generated a war because MS's work
| was... negative.
|
| [1]
| https://archive.org/details/bigbluesunmaking00carr/page/4/mo...
| page 101
| bdw5204 wrote:
| Using production metrics as a whole is very stupid and a good
| way to get devs to optimize for the metrics rather than quality
| work. A contemporary example would be a company that promotes
| for "impact" (i.e. launching new products) which is a great way
| to have a bunch of failed products that nobody maintains!
| gabrielhidasy wrote:
| I know at least a few many-hundred-billion dollar companies
| that fit that description...
| rented_mule wrote:
| As your examples indicate, one reason it's a bad production
| metric is that it's a reasonable measure of the burden carried
| by the maintainers of the codebase. The production metric point
| of view classifies code as an asset. It's closer to the truth
| to view the functionality as an asset, and the code itself as a
| liability.
| coffeemug wrote:
| I'm sure there are engineers who fix a critical bug every few
| months and generate millions of dollars of value, but as a
| general rule great engineers tend to be prolific and engineers
| who aren't prolific tend to not be great.
| syndicatedjelly wrote:
| Engineers who are obsessed with greatness tend to not be
| great either
| AdrianB1 wrote:
| I do a lot of code review for SQL. One thing that I always to is
| reduce the number of lines of code, usually by ~10% on the first
| read. I need to focus not to become a target :)
| cmsefton wrote:
| This comes up often! A few previous discussions:
|
| https://news.ycombinator.com/item?id=33483165 (2022)
|
| https://news.ycombinator.com/item?id=26387179 (2021)
|
| https://news.ycombinator.com/item?id=10734815 (2015)
|
| https://news.ycombinator.com/item?id=7516671 (2014)
|
| https://news.ycombinator.com/item?id=4040082 (2012)
|
| https://news.ycombinator.com/item?id=1114223 (2010)
|
| https://news.ycombinator.com/item?id=1545452 (2010)
| hyperman1 wrote:
| There is a deeper lesson here: Someone was thinking of lines of
| code as an asset, not a cost. It's a an error you also see in
| junior programmers writing reams and reams of code. The lesson is
| a harsh one for us code lovers, at least it was for me:
|
| Code is a means to an end, and an expensive one at that. The best
| code is the code never written. Our job is to solve problems, not
| to write code.
|
| You can use LOC as a crude measure of progress, in the same way
| as tons of concrete used is a crude measure of progress when
| building a skyscraper.
| datavirtue wrote:
| As a developer few things make me glow like deleting hundreds
| of lines of code that have been replaced by simplicity.
| gabrielhidasy wrote:
| Not even that, I'm not a civil engineer, but it looks pretty
| hard to add a ton of concrete without really helping a
| skyscraper, but I could add a few thousand lines of code
| without improving a system one bit, and even more lines to make
| the system slower, more complex, and still not add any
| functionality.
|
| LoC is about as good a measure of a system quality as weight is
| for an aircraft project.
| CrazyStat wrote:
| > LoC is about as good a measure of a system quality as
| weight is for an aircraft project.
|
| This is a very good an analogy. A plane has to weigh
| something, but the absurdity of measuring how much progress
| you've made building a plane by how much weight you've added
| is immediately obvious.
| margalabargala wrote:
| > Not even that, I'm not a civil engineer, but it looks
| pretty hard to add a ton of concrete without really helping a
| skyscraper.
|
| I am also not a civil engineer but I can think of a lot of
| ways to add concrete to a skyscraper in ways that are
| somewhere between nonhelpful and burdensome.
| michaelcampbell wrote:
| You might acknowledge this analogy is popularly ascribed
| originally to Bill Gates.
|
| "Measuring programming progress by lines of code is like
| measuring aircraft building progress by weight." -- Bill
| Gates
| norir wrote:
| This sentiment goes too far in the opposite direction for me.
| Code that solves a problem is an asset. To carry your analogy
| forward, code is the concretization of the solution of the
| problem. The idea of the skyscraper is useless on its own and
| requires the concrete that materializes it. The skyscraper
| would become a lot less valuable if you removed the concrete...
|
| Of course, you also don't make the skyscraper better by
| indefinitely adding concrete. A balance must be found with the
| right amount to be load bearing but not too much. Just like
| code.
| seadan83 wrote:
| It's not a spectrum, instead a duality. An engine is an
| asset, yet it needs maintenance. Because software is soft,
| existing assets become yet more stuff to understand, more
| stuff to fix and keep in sync.
|
| Compare for example a building made of stacked stone, brick,
| concrete, or modular carbon sheets on rebar
|
| Another example, 100 hotel rooms, rearrange the layout and
| it's 101 things to do.
|
| The analogies still fail, software updates are more akin to
| welding an airplane on to a car attached to a subway train.
| It's less, oh, we need to rework these weldzhere, it's often
| trying to make the software do something that is radically
| different. Like inserting a romance chapter into a mystery
| novel that starts as a chemistry how-to
| throwyawayyyy wrote:
| Agreed. And a point that keeps getting missed whenever this
| discussion comes up is there's a big difference between
| junior and senior programmers. What should a junior
| programmer do? Write as much code as possible! KLOC is a
| pretty good measure of progress for junior programmers, how
| else do you get better at programming? To know when not to
| write a line of code, you have to know how to write the line
| of code in the first place.
| hyperman1 wrote:
| Costs are not a pure negative. Just like a skyscraper without
| concrete would be silly, so is an IT solution without code. I
| have no problem paying for extra code, just like I have no
| problem paying for an extra server. IF they are worth it.
| Software engineering is also the act of making a reasonable
| tradeoff.
| jameshart wrote:
| Lines of code are capital. They cost money to make, and they
| cost money to maintain. They can be productive capital, but
| if they aren't, they're a drain on your resources and a
| liability.
| kibwen wrote:
| This is what fills me with dread when it comes to LLM coding
| assistants.
|
| LLMs solve the problem of "we don't have enough code, so let's
| generate low-quality code faster than ever", which, to a first
| approximation, is not actually the problem that anyone has; the
| problem we have is that we don't have the _right_ code, and the
| code that we do have is already shit.
|
| But at least managers will be happy that their reports are now
| checking in +100,000 LoC a day. What could possibly go wrong?
| CapitalistCartr wrote:
| "Our job is to solve problems, not to write code."
|
| My job is what my employers pays me to do. If my employer
| agrees with that sentiment then it is. If I'm volunteering on
| open source, I can do my best, but if my employers rewards
| lines of code, then I produce LOC. Of course, picking a better
| employer factors in there somewhere.
| rsynnott wrote:
| Wait, does anyone _actually_ reward lines of code today, in
| this future year of 2024? Like, I remember people joking 20
| years ago about how it was the sort of thing companies like
| IBM used to do in the 80s.
| CapitalistCartr wrote:
| Lots of people joke about it, but lots of bosses still look
| at it. When your boss treats the most prolific coders as
| the best, it sends a message.
| michaelcampbell wrote:
| Maybe I've been lucky, but I've been in big (10's of 1000's
| of employees) firms and small (10's of employees) firms,
| since the mid 1980's, and have never been measured on LsOC.
| But I play along with the joke, because it's an easy
| strawman.
|
| That said, there are other equally bad metrics that are in
| current use.
| whiterknight wrote:
| Sucks doing something you know is a waste. I value my time
| and personal growth more than my employer does.
| hyperman1 wrote:
| Partially true. One of my less glorious days in IT was spent
| mopping water out of servers. We've all sbeen in situations
| where the best course of action was to shut up, sit down,
| type tons of dumb code, and deal with the fallout later.
|
| But if this happens more than rarely, you either find a new
| job or stay and live with the fact that you've become a
| second rate programmer in a second rate company.
| michaelcampbell wrote:
| I can't believe no one as yet has trotted out the Dijkstra
| quote, so I will: https://www.azquotes.com/quote/754979
| HarHarVeryFunny wrote:
| If you measure productivity by LOC, then generally what you will
| get is lots of LOC. Cut and paste is easy if that's what makes
| you look good.
|
| Of course what companies should really be incentivizing is well
| written code that is easy to maintain and extend, not bloated
| cut-n-paste garbage.
| araes wrote:
| And when somebody figures out how to metricize "well written"
| then that will turn to fecal matter. Re: Goodhart's Law [1]
| (admittedly meant to be economic, yet applies to most metrics).
|
| Also related to Enshittification (see fecal matter), the
| platform shifts, no longer prioritizes quality, and instead
| shifts to whatever "well written" is defined as.
|
| LLM's and especially online song choice algorithms have a heavy
| dose of this. "Make whatever pop music says is 'well written'"
| You have included all the keywords necessary to SEO your
| billboard submission.
| passion__desire wrote:
| Where does Uncle Bob fit into this? Because he sure does love
| to give advice
|
| How small a function should be? https://youtu.be/rXjf8eiGsSI
| araes wrote:
| I think I'm totally missing the reference (apparently the
| Robert in the video?). I thought it was Bob's your uncle
| (instructions complete), or Uncle Bob the photographer (who
| doesn't know how to use his own equipment).
|
| Pretty sure its not a T-800 Terminator or smoking pot like
| Bob Marley reference.
|
| Also, totally feel like an LLM doing the %chance this word
| game.
| HarHarVeryFunny wrote:
| Google Robert Martin => "first chairman of the Agile
| Alliance".
|
| Wouldn't the really agile thing be to get rid of alliances
| and chairmen in charge of telling people how to develop
| software?
| analog31 wrote:
| This is what I always think of when someone tells me that AI will
| replace coders. I tell them: "A coder can only write about 100
| lines of good code a day, but I look forward to when the AI can
| write 100 million lines of code a day."
| continuational wrote:
| In evaluating software value, lines of code fall under the
| denominator.
| sircastor wrote:
| For all the people dismissing lines of code as a metric, I want
| to point out that very early on a line of code was literally a
| CPU instruction. While there was certainly something to be said
| for efficiency of your subroutine, lines of code was not a
| totally unreasonable measurement of things that your program was
| doing. Obviously we get removed from that the more we abstract
| and well constructed code is different from lines of code, but I
| can see where they were coming from.
| kbolino wrote:
| One of those CPU instructions (or one class of them anyway) is
| called a jump. It allows you to move to a different instruction
| than the next one, including going backwards. There has always
| been reusability of already written code in digital computers.
| LOC was no more or less meaningful when code was written in
| assembly or machine language than it is today.
|
| It only measures something loosely correlated with progress
| toward completion and only if you know what done looks like.
| gjkood wrote:
| Early in my career I once optimized an inherited 10,000+ line C
| program to less than 500 lines. It was a C program making SQL
| calls into a Sybase database.
|
| No, not because I had some brilliant insight but for the simple
| assumption that my predecessor may not have been aware of how to
| write functions or use parameters to supply variable data to the
| SQL query. They had literally written the same SQL statement
| inline with a couple of changed values in each SQL call.
|
| I just rewrote the code making the SQL call as a function call
| with bind variables as parameters into the function. All the
| replicated inline code was replaced with the function being
| called in a loop with the changed bind values supplied from an
| array.
| papichulo2023 wrote:
| Yooo, no params == no injection /s
| mig39 wrote:
| Was this the original TPS report?
| varjag wrote:
| It was a great write up in its time but has since become a goto
| cliche for people who can't write much code.
| sandspar wrote:
| Article: "Did you know that geniuses like Einstein tend to be
| night owls?"
|
| Unemployed guy who wakes up at 11 a.m. every day: "I must be a
| genius!"
|
| Barba non facit philosophum: a beard doesn't make one a
| philosopher.
| torginus wrote:
| I never understood why is it when people talk about LoC of code
| written, they always use 'lines added - lines removed'. If I do a
| run 10km run and end up in the same place I started, it's not a
| 0km run.
| vacuity wrote:
| I think a part of it is that dumb diff tools may record large
| diffs when the change in functionality is limited and the rest
| is more or less moving lines around. Like making
|
| if cond { ... return; } ...
|
| into
|
| if cond { ... return; } else { .... }
|
| But that's not comprehensive either.
| cromulent wrote:
| It's the wrong metric. We all know that. It's like measuring a
| manager by "meetings attended" or something like that.
|
| The hard part is measuring the effectiveness of people whose
| output is realized in the future, not today.
___________________________________________________________________
(page generated 2024-03-23 23:01 UTC)