You're equating code size with code quality, which in my opinion is an unqualified assumption. Unfortunately, most of the software engineering literature disag

You're equating code size with code quality, which in my opinion is an unqualified assumption. Unfortunately, most of the software engineering literature disagrees. We know few things in software engineering. One of them is more code == more bugs. Your comment about X > Y is true, but you're replacing one false binary choice with another. Again, as Apple has demonstrated over and over again with every single one of their products, fewer features, implemented well will outearn products that have more features implemented poorly. So, I'd argue that the choice isn't between reducing the size of Microsoft Excel from 15MB to 14MB and adding a stretch goal feature. It's between keeping Excel at 14MB (or whatever its old size was), fixing bugs and polishing the hell out of it or growing Excel to 15MB and adding some more buggy half-assed features to fill out the checklist on the back of the box.