Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

-2000 Lines of Code (2007)

folklore.org

Post reply on HN
Print view View original

111–120 of 222 posts

Re: -2000 Lines of Code (2007)

#111

Post by CrazyStat »

gabrielhidasy wrote: post #104
hyperman1 wrote: post #99

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 crud…

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.

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

Re: -2000 Lines of Code (2007)

#112

Post by samatman »

userbinator wrote: post #25

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?

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

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 ΔSLOC count may or may not be more productive than a peer who has a week or two of no ΔSLOC 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.

Re: -2000 Lines of Code (2007)

#113

Post by samatman »

chii wrote: post #5

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

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.

Re: -2000 Lines of Code (2007)

#114

Post by pixl97 »

patrickmay wrote: post #106
octopusRex wrote: post #34

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 o…

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.

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.

Re: -2000 Lines of Code (2007)

#115

Post by samatman »

arrowsmith wrote: post #10
Almondsetat wrote: post #8

Earlier quoted context omitted.

This also goes for Goodhart's law itself

https://xkcd.com/2899/

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.

Re: -2000 Lines of Code (2007)

#116

Post by samatman »

datavirtue wrote: post #107
threatripper wrote: post #40

Earlier quoted context omitted.

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.

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.

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.

Re: -2000 Lines of Code (2007)

#117

Post by convolvatron »

khazhoux wrote: post #24

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 c…

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.

Re: -2000 Lines of Code (2007)

#118

Post by samatman »

wesselbindt wrote: post #84
khazhoux wrote: post #24

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 c…

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…

> There is 0 correlation, none whatsoever

This is quite unlikely to be true. No correlation at all?

Especially if we shift to ΔSLOC 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.

Re: -2000 Lines of Code (2007)

#119

Post by HarHarVeryFunny »

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.

Re: -2000 Lines of Code (2007)

#120

Post by samatman »

eviks wrote: post #55
khazhoux wrote: post #41

Earlier quoted context omitted.

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…

confirmation bias indeed works that way more often than not: it confirms what you already believe

If you declare by fiat that every confirmation is confirmation bias, you've made knowledge impossible.
Post reply on HN