# of lines of codes is a super-valuable metric when used relatively to compare two different things in software.

For example, I worked a .NET project with a central form that had close to 30K lines of code. This was 10x in comparison with anything else in the app. This is clearly a "whale" of a problem.

The lines-of-code comparison made it much easier for non-technical staff to now understand why this "one form" (really dozen of different functions contained in a single form) was troublesome in terms of fixes, enhancements etc. and also why no one wanted to touch it.

Parent explained in a metaphor how both metrics (more lines, less lines) can be bad.

Maybe engineer A has a easy feature to do. Lots of lines of code but it's smooth sailing. Another engineer, B, has a tricky bug fix to do, which requires him to read documentation, navigate the fode, reproduce the issue, until he published a fix with a handful of lines of code.

Who's the better engineer, A or B?

Even if we consider the average over time, one may be getting more tricky features than other. Or spending time in tasks such as hiring, mentoring, etc, which is worth a lot to companies.