[bee_rider]

“Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.

And anyway, I’m pretty sure what people really mean by this “less is better” mantra is: the lowest amount of code that still accomplishes the goal and is still readable is preferred. Linux apparently has 40M lines of code, and I bet most of it is better than mine. Some things just take lots of code.

Which seems to leave room for these agent salesmen to pitch SLoC as a plus. We just have to believe those lines are all good ones. I that case, it would be impressive. I don’t believe it, but they are probably pitching to people who do.

[the_af]

> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.

I think it is (or should be) a goal & business-oriented concern as well, not just an engineer's who enjoys their craft.

More complex systems are worse than simpler systems (that accomplish the same), in cost, maintenance, fragility, ease of understanding, etc. Fewer moving parts usually result in higher reliability, fewer things that can break down or fail to interact properly, etc. That's a business concern too, not just engineering craftmanship or whatever. Business people should care about this too.

I don't think this is the same as bikeshedding over irrelevant details, something we software engineers are often prone to. Monstrous complexity does impact the business!

[ryandrake]

It's like we've all forgotten what technical debt means. We just say the phrase, but we have forgotten that it is analogous to actual debt. Every line of code produced should be treated as a liability to the company, like a bond they issued that they have to pay interest on in the future. You only take on the liability if it produces more business value than it costs to maintain. The goal is not to issue as many bonds as you possibly can.

[embedding-shape]

> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right?

No, it's the perspective of a programmer who wants the project to not be bogged down too much in technical debt so every change gets slower and slower to implement, as everything gets more intermingled. A clean design helps you move faster for a long time, compared to a design that is fast to implement but makes it hard to move forward properly in the future, without resorting to shortcuts and/or hacks.

> Some things just take lots of code.

True. Rich Hickey does a good job differentiating between what's complicated because the domain is complicated, VS what's complicated because the implementation just ended up that way, even though with some more thought and design, could have been made a lot simpler.

[jimbokun]

Less is better is the position of the engineer who has seen some shit and whose career lived to tell about it.