3 ms·
> 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
by ben_w 4mo ago
> 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 4mo agoSurvivorship 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 4mo ago> 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.
- bsenftner 4mo agoWell, 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 4mo agoI 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.
- resonious 4mo agoOver optimizing and spending too much time on engineering decisions is also something an incompetent development team would do.
- deleted 4mo ago[deleted]
- ben_w 4mo ago> 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 4mo agoI 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.
- preisschild 4mo agoGood point. In my experience even hobby free software projects are generally better engineered than most proprietary software sold by businesses
- rusk 4mo ago> 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.
- 21asdffdsa12 4mo agoThe 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.
- nyeah 4mo agoLines of code are a business liability. They are future cost.
- andrewaylett 4mo agoThere'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.
- jmcqk6 4mo ago> 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.
- kingds 4mo agoI'd argue PayPal was a successful business, not a successful piece of software.
- ben_w 4mo agoThat'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.