-2000 Lines of Code (2007)

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

by colinprince • 2 years ago

256 211 2 years ago

folklore.org

1letterunixname• 2 years ago

+KLoC is a terrible KPI that optimizes for complexity, waste, and artificial job security-seeking behaviors.

ck45• 2 years ago

It‘s Goodhart‘s law: "When a measure becomes a target, it ceases to be a good measure"

enva2712• 2 years ago

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• 2 years ago

This also goes for Goodhart's law itself

arrowsmith2• 2 years ago

Lines of code is a bad measure even if it's not a target.

threatripper2• 2 years ago

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

_ZeD_• 2 years ago

they are not a KPI in the first place. loc is not a performance index of any kind.

solumunus• 2 years ago

How can it be a KPI if it doesn’t measure performance?

rsynnott6• 2 years ago

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

eloisant2• 2 years ago

It's obvious today to everyone, unfortunately we replaced that by KPI that are no better.

chii3• 2 years ago

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• 2 years ago

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.

bickeringyokel3• 2 years ago

The question is really more do they actually act on the feedback on a regular basis?

xiphias2• 2 years ago

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.

eloisant2• 2 years ago

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• 2 years ago

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.

rsynnott6• 2 years ago

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• 2 years ago

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• 2 years ago

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.

kbolino2• 2 years ago

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.

Cheer21712• 2 years ago

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.

chii3• 2 years ago

free and open source software around the world.

aka, you are not economically valued, and in order to be artisanal, you have to sacrifice monetary gains to achieve it.

if it is your startup, you can write code however you want.

yes that is true, but a startup is much more than just code. it's a business - with all of the extra work that entails.

samatman10• 2 years ago

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.

chii3• 2 years ago

While the article mentions form filling, that isn't the point.

The point is that there are management styles out there that tries to objectively measure a software engineer's performance (poorly). And unless you are someone with high clout in the organization, you are subjected to it regardless of whether you like it, it making sense, or it being used to control the employees (politics).

knallfrosch• 2 years ago

AWS has 136,000 employees. Of course they're mired in management and processes.

Simply work for a smaller company..

bickeringyokel3• 2 years ago

The cynic in me believes managers actually don't want good metrics because then they have evidence of their bad leadership.

hinkley3• 2 years ago

It’s why they love claiming “culture fit” on anyone older than them. 28 year old managers feeling threatened by 30 year old employees.

bickeringyokel3• 2 years ago

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.

pietroppeter• 2 years ago

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.

praptak2• 2 years ago

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.

anonzzzies2• 2 years ago

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• 2 years ago

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.

drpixie• 2 years ago

When I managed software for a large corporate, I kept a box of pencils on my desk.

For around 1/2 the information requests that came through the department (always very important, we need the info now, it will save/make big dollars) the obvious answer was "Work it out from the info you already have. You've got a calculator and spreadsheet - would you like a pencil?"

Better to avoid the system handling X than having multiple special cases bulking up the systems, most of which only get used once in a blue moon. No one knows the special cases/programs are there, or what actually do. Even if well documented, no one spends the time required to know what's available. So most of those special features are actually waste of time.

hinkley3• 2 years ago

Gave myself RSI deleting <600 LOC with vi.

On the plus side I replaced an O(n²) algorithm with a faster one in the very next commit. Needed to get rid of the ninety copies of the same bad idiom first.

hsjsbeebue2• 2 years ago

600dd:w shouldn’t cause RSI ;)

hinkley3• 2 years ago

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.

selcuka• 2 years ago

Gave myself RSI deleting <600 LOC with vi.

Why? Didn't you know the shortcut `d600d`? /s

mehdix2• 2 years ago

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.

jpc0• 2 years ago

when I reverted to using regex

Begrudgingly I hope...

If you replaced 4000LoC with a regex that regex scares me...

veidelis2• 2 years ago

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• 2 years ago

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.

joaquincabezas• 2 years ago

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

khazhoux19• 2 years ago

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• 2 years ago

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.

xandrius3• 2 years ago

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)

khazhoux19• 2 years ago

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.

supriyo-biswas• 2 years ago

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.

octopusRex2• 2 years ago

Do you really expect most managers, if any, would do this?

khazhoux19• 2 years ago

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.

Ultimatt• 2 years ago

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• 2 years ago

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

mdp20212• 2 years ago

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.

pflenker2• 2 years ago

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.

khazhoux19• 2 years ago

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.

ZaoLahma• 2 years ago

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.

khazhoux19• 2 years ago

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.

ResearchCode9• 2 years ago

Why have they reported at every standup the last six months

Every what?

khazhoux19• 2 years ago

Standup. Daily meetings where teams talk about their blockers and so forth.

erinaceousjones2• 2 years ago

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.

wesselbindt3• 2 years ago

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.

samatman10• 2 years ago

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.

khazhoux19• 2 years ago

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.

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• 2 years ago

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.

convolvatron2• 2 years ago

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.

khazhoux19• 2 years ago

What's all this business about ranking that you're talking about? I didn't mention it. And asking engineers to rank each other? Seems you've picked some bad companies to work at.

You should consider working somewhere where management is deeply technical. At everywhere I've worked, the entire eng-management chain (up to CEO) fully understood the domain (as you put it), the state of the art, the key system architectures, and so on. The idea that an eng manager's role should be limited to "developing human relationships and being attentive", would simply not fly.

Eng managers need to be able to go into code, and they must be able to gauge the complexity of the work under them, or they'll be unable to spot the difference between someone aggressively chasing a nasty heisenbug for weeks, versus someone struggling for weeks to put together a basic block of working code.

userbinator• 2 years ago

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?

xandrius3• 2 years ago

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.

anonzzzies2• 2 years ago

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.

praptak2• 2 years ago

Worse, because codegolfing the entire codebase is undesirable.

samatman10• 2 years ago

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.

seadan834• 2 years ago

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

seadan834• 2 years ago

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_• 2 years ago

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.

hsjsbeebue2• 2 years ago

The moral: even if you are smart as Einstein you are still an employee and need to do employee things.

datavirtue4• 2 years ago

If Einstein was pressured by metrics we would have never heard of him.

michaelcampbell6• 2 years ago

I suspect he was... as a patent clerk. And that may be why we never heard of him THEN.

octopusRex2• 2 years ago

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• 2 years ago

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• 2 years ago

Found it on youtube: https://www.youtube.com/watch?v=toSRmKKiosQ

patrickmay• 2 years ago

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• 2 years ago

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.

SillyUsername• 2 years ago

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

jameshart2• 2 years ago

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.

Taniwha3• 2 years ago

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• 2 years ago

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

Taniwha3• 2 years ago

I think it started out in ROM, it has low core jump vectors so that portions can be replaced (rather than just the whole thing) I worked designing Mac graphics accelerators back in the day, we hooked them up by replacing bits of QD through these vectors. So over time rom fixes got made and some of it would have come off of disk

If you follow that second link you'll find a zip file with quickdraw source in it, you'll find that while there is a little pascal (.p files) most of the core is assembler (.a files)

JoeAltmaier• 2 years ago

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• 2 years ago

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• 2 years ago

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!

gabrielhidasy2• 2 years ago

I know at least a few many-hundred-billion dollar companies that fit that description...

barcist2• 2 years ago

The trick is to align the metrics with company goals. It's not easy, but not impossible either.

For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones).

Obviously your customer support needs a different metric.

rented_mule• 2 years ago

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• 2 years ago

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• 2 years ago

Engineers who are obsessed with greatness tend to not be great either

talsperre• 2 years ago

In my opinion, there is still some relation between LoC and engineering output over a long period of time. Some of the greatest computer scientists and engineers have insane code outputs and I believe it does directly translate into impact in some ways. The issue is when Loc becomes a metric to measure performance. At that point, we have an instance of Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.”.

AdrianB1• 2 years ago

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• 2 years ago

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)

hyperman13• 2 years ago

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.

datavirtue4• 2 years ago

As a developer few things make me glow like deleting hundreds of lines of code that have been replaced by simplicity.

gabrielhidasy2• 2 years ago

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• 2 years ago

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• 2 years ago

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.

michaelcampbell6• 2 years ago

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• 2 years ago

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.

seadan834• 2 years ago

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• 2 years ago

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.

hyperman13• 2 years ago

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.

jameshart2• 2 years ago

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• 2 years ago

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?

CapitalistCartr2• 2 years ago

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

rsynnott6• 2 years ago

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.

whiterknight• 2 years ago

Sucks doing something you know is a waste. I value my time and personal growth more than my employer does.

hyperman13• 2 years ago

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.

michaelcampbell6• 2 years ago

I can't believe no one as yet has trotted out the Dijkstra quote, so I will: https://www.azquotes.com/quote/754979

HarHarVeryFunny3• 2 years ago

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.

araes2• 2 years ago

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• 2 years ago

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

analog31• 2 years ago

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• 2 years ago

In evaluating software value, lines of code fall under the denominator.

sircastor• 2 years ago

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.

kbolino2• 2 years ago

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• 2 years ago

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• 2 years ago

Yooo, no params == no injection /s

walth• 2 years ago

https://www.folklore.org/Discovered_Loops.html?sort=date?sor...

mig39• 2 years ago

Was this the original TPS report?

varjag• 2 years ago

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• 2 years ago

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.

TRiG_Ireland• 2 years ago

But the fact that some geniuses were laughed at does not imply that all who are laughed at are geniuses. They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown.

― Carl Sagan

torginus• 2 years ago

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• 2 years ago

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• 2 years ago

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.

-2000 Lines of Code (2007)

Related Stories