This sounds wrong, features have to be the value of your code. The required maintenance and slow down to build more features (technical debt) are the liability, which is how I understood the relationship to "lines of code" anyway.

Wrong or not, the industry embraced it.

I can sort of understand it if I squint: every feature is a maintenance burden, and a risk of looking bad in front of users when you break or remove it, even if those users didn't use this feature. It's really a burden to be avoided when the point of your product is to grow its user base, not to actually be useful. Which explains why even Fischer-Price toys look more feature-ful and ergonomic than most new software products.

> A better formulation is "every feature is a liability". Taking it to the line of code level is too prescriptive.

Amount of code is a huge factor but maybe not the best wording here. It's more a thing of complexity where amount of code is a contributing metric but not the only one. You can very easily have a feature implemented in a too complex way and with too much code (esp. if an LLM generated the code but also with human developers). Also not every feature is equal.

> Occasionally writing more verbose code is preferable if it makes it easier to understand.

Think this is more a classic case of "if the metric becomes a goal it ceases to be a metric" than it being a bad metric per se.