These two statements are not compatible: > When an engineer like this proposes something that adds unnecessary complexity, it's usually hard to argue with. The

These two statements are not compatible: > When an engineer like this proposes something that adds unnecessary complexity, it's usually hard to argue with. The proposed change typically does indeed make the system objectively better > But the overall system becomes a little more brittle, and a little harder to reason about, two things that are much more difficult to measure than memory and power. Complexity is your enemy. Complexity is something you need to have a strong motivation for, and if the system becomes more difficult to maintain moving forward it is not, in fact, objectively better. In the long run, you're going to spend more time maintaining code. In many cases these engineers are good at optimizing for something, and they enjoy doing that. Optimizing for something like memory or power is, as you said, easy to measure and easy to "gamify" by improving metrics. What you need to do is encourage these engineers to find other metrics to focus on, even if they're a little softer. For all their faults, getting engineers to consider things like total LoC, complexity metrics, etc as something to work toward improving may get them to redirect their focus in more productive areas. It's not that their existing focus areas are bad, they're just an incomplete view of the overall priorities.