Comment by xyzzy123 | Hacker News Reader

Comment by xyzzy123 | Hacker News Reader

LOC are not all the same.

My heuristics for assessing the difficulty of changes revolve around "load bearing-ness".

It's basically free to change code no one uses. It's not bearing any load. If your metric is LOC you can be very "productive"! But from another perspective you cannot tell if you are productive yet, the value is not realized until people pay for it and rely on it.

Changes in software that people use affect "load bearing" LOC. There is "pucker factor".

You can kinda multiply together: what is the inherent complexity of the domain, is the change reversible, is your change stateful, how many customers use it, how deeply do they interface with it, how many stakeholders are involved in the change, what are the consequences of failure / mistakes, how many cases / paths do you need to test - to get a feel for the true difficulty of a change.

The difficulty of a change is separate from the value it creates, but often they're related. Why? Because in widely used software if a thing lots of people valued was easy, it would already be done. Of course pathologies do exist where people do difficult things for no good reason or foolishly leave easy money on the table.

Greenfields / startups are a special case / time, where difficulty seems temporarily uncoupled from value. You can make huge and potentially valuable changes quickly and easily if no one is using your thing. But there is no free lunch because the downside is that you are only creating potential value, you still have risk that all the code you wrote is useless.

This is why some some people might say 30 LOC / day is a lot while others might name a much higher number. The people saying the lower number are the ones with existing customers, they are talking about "load bearing" LOC.

I'd say a very useful and simple formula one could device can look something like:

f(n) = x/y. value = goal/loc.

"goal" here is just arbitrary number of usefullnes of code that aligns with some common uility like say 10 = ASI/eternal happiness and immortaility or whatever while 1 being 'terminator' and 7, 8 being useful business code so on. loc is self-expplanatory.

>goal / >loc -> < 10/1 a; <goal / >loc -> < 10/1 b; <goal / <loc -> < 10/1 c; >goal / <loc -> = 10/1 d

So, the very best value possible will be say "d" 10, f(n) = 10/1 - any other of the 4 possible permutations aka options will lead to worse result:

But while such simple formula could illustrate the value of software project overall, a key detail ommited could be the lowest possible number a great goal may require, most people would agree writing ASI in just <100 words aka 'one line' is just not possible, or anything useful.

It's like complaining you could write 100 000 a day when the project is Operating system or 3dsmax clone, it surely will be better to finish it early and there is a lowest bar possible that cannot be decreased even with F# or whatever language that saves words.

I was not able to make much sense of that, but if you can create 10k+ lines of good C per day regardless of domain complexity, requirements etc, you could create ffmpeg solo including all codecs in under 6 months.

That would make you, approximately, the best programmer in the world.

well maybe but btw i swear this almost looks like P=NP but rather reversed P=NP lol, let me explain...in the classic p=np problem given to explain it it's the subset problem where it's easy to verify a solution, but not find it {25,39,22,12,29,18} - do any 2 numbers add to 47 and yeah the last 2 numbers: 18 and 29 add to 47. Yet here if you use LLM to make great product, you have a "solution" pretty quickly but verifying it will take some time...be it to test functionality or read every single line and understand it. It's such a weird logical puzzle! The llm throws you the solution basically saying 'i did it' and your verification takes longer, another way to look at is that your verification is the real solution while the code generation is the "verification"...confusing a lot.

edit: in my previous post i meant that the higher the challenge of the program / the lowest possible lines of code to implement it will be the best possible software one can make. So a software rated 10/10 in every aspect possible implemented in just a single line of code is the best possible program. If you write it in more lines of code, it's worse in terms of value, if you decrease the quality but keep the loc low...it's still not optimal since you sacrifice quality, if you decrease the quality but increase the loc that's the worst possible case.

It sucks to do a 2-line change that requires 2 weeks of validation :/

Agree that codegen can flip the effort from creating to validating. Some people believe the "true" intellectual capital created by the software development process is the understanding created inside the team's mind as they build it (not the code itself). Like, understanding of the domain, customers, market, how the software works, how they would build it again if they had the chance, their networks and relationships etc.

Probably it does hurt if codegen impacts that process. It's always been possible to externalise some of that understanding, by writing books, articles etc. I suppose what we are starting to see is that kind of intellectual capital will gradually reside in AI also. For well understood problems (TODO app, space invaders, etc) the model will have the actual understanding and everyone generating those apps for the first time would need to build it up.

I agree that 1 LOC that provides infinite value sounds like the "best possible program", but beyond that I can't see any hard and fast rules about LOC vs value, I think they're almost entirely uncorrelated. Mostly it's about what the lines do, but even then it's hard. What's more valuable: the bible, the script to star wars or a set of 747 technical manuals? Should they have used more or fewer words to achieve their goals?

Even with precise specifications the "best" way to implement large scale software is never clear and depends on many factors. Sometimes more duplication is better, sometimes you need more abstraction to reduce it. A lot depends on what your team (or contributors) are comfortable with and their abstraction ceiling.

Reply on news.ycombinator.com