When you have less code, you have less code to write, you have less code to read, you have less code to understand, you have less bugs, you have a smaller team,

When you have less code, you have less code to write, you have less code to read, you have less code to understand, you have less bugs, you have a smaller team, or, for the same budget, you have more time to do new features and bug fixes, you then have more customer satisfaction, you then have more money for even more features and bug fixes. All at the same time. I think blanket statements like this are short-sighted, dangerous, and just plain wrong. Less code doesn't automatically make anything easier to understand. When my JavaScript is optimized, for instance, it's certainly less code than I wrote. But it's absolutely not understandable. Less code doesn't automatically reduce your bug count. I can have as many bugs in 40 lines of code as I can in 400. Less code doesn't give you more time to add new features or fix bugs. In fact, if your code is less understandable, you're going to have a lot of cognitive debt which will increase the amount of time it takes to understand and add new features. Less code isn't useful. Understandable code is. Sometimes those ideas align. Sometimes, though, understandable code is more verbose. Instead, you should write ENOUGH code to get your task done, and then refactor.