Live data from Hacker News

-2000 Lines of Code (2007)

folklore.org

181–190 of 222 posts

Re: -2000 Lines of Code (2007)

#181

Earlier quoted context omitted.

But they ARE a KPI that is easy to understand and measure.

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

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

Re: -2000 Lines of Code (2007)

#182

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?

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.

Re: -2000 Lines of Code (2007)

#183
post #149

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

[deleted]

Re: -2000 Lines of Code (2007)

#184

Earlier quoted context omitted.

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

I think we agree with each other? Or mostly so. ΔSLOC 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…

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.

Re: -2000 Lines of Code (2007)

#185

Earlier quoted context omitted.

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

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

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.

Re: -2000 Lines of Code (2007)

#186
post #54

Earlier quoted context omitted.

Might that hint that the problem that is there is that the metric is bad?

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?

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.

Re: -2000 Lines of Code (2007)

#187
post #126

Earlier quoted context omitted.

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…

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

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.

Re: -2000 Lines of Code (2007)

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

Re: -2000 Lines of Code (2007)

#189

Bill Atkinson, of Atkinson Dither fame. https://beyondloom.com/blog/dither.html

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.

Re: -2000 Lines of Code (2007)

#190
post #123

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…

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…

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.
Post reply on HN