[andrewaylett]

The thing is: I could produce 2-3 times as much code as before _without_ an LLM, if I didn't care about my colleagues' ability to review my output properly.

Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.

A huge part of the job of Software Engineering is producing the right amount of code at the right time.

[ben_w]

> Lines of code are a liability, not an asset. You want as few of them as you can get away with, without compromising the actual asset: the functionality.

> A huge part of the job of Software Engineering is producing the right amount of code at the right time.

Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small.

120 kloc mostly from one single developer copy-pasting and keeping non-compilable code for an obsolete target "for reference" for a decade, becoming both a ball of mud and a whole pantheon of god classes? No unit tests, no code review? Won awards.

Properly engineered, mandatory code review, mandatory unit tests, dev meetings to knowledge-share? People with the money said too slow, closed it down.

(Sometimes people bring up how bad Musk's code was at PayPal. I never bothered investigating. Successful product though, wasn't it?)

[hatefulheart]

Survivorship bias, you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise, or a product that is possible within constraints that otherwise could have been a success, but not realised by sloppy work and incompetence.

Furthermore the dependencies you choose to build your product are presumably filtered for engineering practices or world class engineers. So given the choice you yourself prefer top quality engineering, so do your customers. Much in the same way you are a customer of your projects dependencies. Difference being, as developers we get to see how the sausage is made, our customers only see second and third order effects.

[aiisjustanif]

> you don’t know of all the failed projects that couldn’t get off the ground because of incompetent development team and practices that lead a product to its demise

Trying to ignore the nuance is hard in your position or the following one I’ll give is difficult.. but is the opposite potentially true as well? We don’t know how many projects failed because of over optimizing, too much time spent on design and engineering decisions. It’s of getting out and MVP to market. I only say this because I have been apart of a few of these.

[resonious]

Over optimizing and spending too much time on engineering decisions is also something an incompetent development team would do.

[bsenftner]

Well, that's the other side of incompetence: they know how to spin their tools, but they don't know when to stop, or how to stop the change requests, the balance between shippable, maintainable, and what the market wants at that time.

[hatefulheart]

I understand and of course I am familiar with the hypothetical you are trying to set up here but I was specifically pointing out a logical fallacy I see banded round all the time by people who should know better or educate themselves.

I will say that if “good engineering practices” comes up in your root cause analysis for a failure to launch a product you are not thinking critically.

[ben_w]

> Survivorship bias

The statistical problem is small sample size, not survivorship bias, as I got to see things before failure. These two examples are merely illustrative of things I've seen.

[miltava]

I think both are at play here and I don’t know about Musk’s programming skills. But it seems that they had other very good programmers (including levchin). So maybe business success can buy good engineers to clean the messed up code. I’m not sure how it goes with AI now though.

[jmcqk6]

> Absolutely true, however my experience says that the correlation between "good software engineering practices" and "positive business outcomes" is, at best, small.

One of the most uncomfortable truths about our profession is that there is no floor to how bad software can be while still making people billions of dollars.

[21asdffdsa12]

The first thing they buy of the success money though, is a struggling technical competitors, so that this team can clean up there mess. This would mean that AI is only a good contributor at startups and with prototypes.

[preisschild]

Good point. In my experience even hobby free software projects are generally better engineered than most proprietary software sold by businesses

[andrewaylett]

There's a trade-off to be made, and it's not necessarily clear where the trade-off sits for any particular company, or even team within the company.

One product person described it as eating vs breathing. Availability is like breathing: if you stop being available (including, but not limited to, because your software is a big ball of mud) then you're going to die pretty quickly. Product is like eating: you might not die so quickly but if no-one's buying what you're selling then you're still not going to survive.

The team I'm part of is a platform team, so we're closer to being lungs than being stomach. We can (and I appreciate being able to) focus more on stability than feature development.

[rusk]

> Successful product though, wasn't it

If you can call being an “also ran” in a field they had a ten year march on their competitors in success, yeah.

Truth be told it was the shoddy code they were forced to use for the vanity of their paymaster might well have held them back, though manifestly that is not a bad thing. Probably the best outcome, really.

[kingds]

I'd argue PayPal was a successful business, not a successful piece of software.

[ben_w]

That's kind of the point.

The software only had to be good enough to support the business. It doesn't have to win a Turing Award, and probably wouldn't help the business if it did.

[nyeah]

Lines of code are a business liability. They are future cost.

[DanielHB]

> Lines of code are a liability, not an asset.

I have been saying this for years, I once had a heated argument about a small system of maybe 1000 lines of code that was technically superior and more scalable but was freaking 1000 lines of code to maintain compared to the quick and dirty 10 lines of code it was suppose to abstract and make generic (for future use of course).

That with also countless debates over insignificant features in frontend apps at the cost of extra code. Frontend code is very susceptible to this maintenance cost dilema.

Many developers are too focused on delivery value compared to maintenance cost. It is unfortunate that non-technical management can see value delivered, but not maintenance cost incurred. With LLM-assisted code this has become many times worse.

[SkyBelow]

>Many developers are too focused on delivery value compared to maintenance cost.

The way this is worded feels like it leaves the blame on developers. Aren't these developers focused on exactly what they are being judged by? Shouldn't we say it is the management who is too focused on delivery value compared to maintenance cost? Is it the developer's job to guide management or the manager's job to request guidance, assuming such guidance is needed?

We need to make sure the responsibility to resolve this problem falls on those with the power to act on it, and in this, developers tend to be receiving far more responsibility to fix than power to fix.

[DanielHB]

I don't think so, my experience is that most often falls into two scenarios:

1) The devs pushing for more complex solutions, covering obscure edge case scenarios, feature-creep, "future-architecturing" because they are more interesting to implement. Classic over-engineering problems.

2) The features the managers actually want are usually boring or annoying to implement and the devs just work around any big architectural problems caused by the feature delivery.

1 is 100% on the devs, 2 it varies wildly, the willingness to address architectural problems are often under pressure by time-delivery estimates from managers. But many devs (especially in companies with low morale) will often just work around issues because addressing the underlying problems can be very difficult and/or time consuming.

Meaning either the dev wants to do the right thing but doesn't have the time, or the dev doesn't care enough and just pushes the tech debt down to the future (when hopefully they will be at another job).

LLMs makes both problems significantly worse, although they are also often very helpful with the big restructurings mentioned in 2. The dev can still be lazy and the deadline can still be too tight even with that extra LLM help.

[tukantje]

How is covering obscure edge case scenarios overengineering?

[aiisjustanif]

I don’t think this is a great argument for such a small amount of LoC. 1000 lines depending on the service it provides could be very small.

[pluralmonad]

> more scalable but was freaking 100000 lines of code to maintain compared to the quick and dirty 1000 lines of code...

[hughw]

I wonder though if, as long as you have LLMs to maintain the extra code, it's worth it to gain the new feature. Less tech debt than your intuition expects.

[andrewaylett]

Why would an LLM be any more capable of maintaining the extra code than I am?

[budsniffer952]

Because it can read and understand the code base far beyond your ability.

You can pretend that's not true, but it is. And it's only going to get better.

[hughw]

Sure man, knock yourself out.

[eiifr1]

"Lines of code are a liability, not an asset."

wrong framing imo

EXCESS lines of code are a liability.

Code of course is an asset.. what other real asset is producing cash-flows? lol come on.

[reverius42]

It's apples and oranges. Lines of code is just a measurement. You can't look at a whole codebase and say "these X lines are essential, those Y lines are excess, delete those" -- the lines interact with each other to create the whole thing.

It would be like saying "Weight in kilograms of course is an asset for an airplane. That's what keeps it in the air. What other real asset is the airplane made of?"

[another_twist]

This is the thing. You "spend" lines of code, you dont produce it. The produced part is the outcome - a functional feature, stability improvements, some business outcome. Measuring productivity with LoCs is like measuring output with cash burn.

[RicardoLuis0]

> Measuring productivity with LoCs is like measuring output with cash burn.

companies are doing that as well lol (re: tokenmaxxing)

[epolanski]

I think that coding reviews are no longer feasible as they used to.

The pace and expectations have increased and a human can barely cope with reviewing its own code, let alone colleagues'.

They are not going to disappear in critical aspects of a codebase, nor shouldn't, but the industry will eventually reward self sufficient individuals able to keep the pace, harness and run adversarial reviews against the design and implementation autonomously.

I'll also say the harsh truth. A well implemented adversarial flow will do either better than your peers or will deliver 95% of the value at a fraction of the cost.

The industry has never valued product, let alone code quality except in places they are core to the business.

Otherwise you would not have MIT-bred leetcode ninjas writing react/tailwind bugged monstrosities at half a million/year for billion dollar products.

[snarg]

How'd that go for the most recent Windows update?

[NotAFurry2]

"A huge part of the job of Software Engineering is producing the right amount of code at the right time."

But the whole job of the owners is to lower the costs as much as possible to produce the product, especially in an environment with higher costs to borrow (higher interest rates at the fed)

[davidpapermill]

> A huge part of the job of Software Engineering is producing the right amount of code at the right time.

I'd go further and say that usually the goal is to use as little code as possible without sacrificing readability.

Brevity is compression, and compression surfaces the salient points of a problem.

Elegance often comes down to brevity.

[sidewndr46]

This is one of the things I ran into early on. LLM needs to compute the determinant of a matrix? Sure, just spit out some huge hyper optimized implementation of it. Good luck maintaining that. Slapping "use industry standard open source libraries for common functions" has improved the quality of LLM output for me by such a large margin.

[bigbuppo]

So it's like jazz... it's the code you didn't commit that matters?