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