> The proposed change typically does indeed make the system objectively better, and they're the one taking responsibility for doing the work and ensuring its correctness. 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.
I work with a lot of people like this, and the key is to bring them to the realization that making a system objectively more featureful or capable does not necessarily make it objectively better: simplicity has value too. One of the key attributes of an embedded system is its longevity. If they want to make something complicated and they're the only person who will ever need to debug or understand it, that's fine, they can make it as complex as they like. But if you need a bus factor greater than 1, or work with other people, they need to design it with other people using it in mind.
Any engineer can make a complicated thing to solve a complicated problem. But the mark of a great engineer is that they can make a tool to solve that complicated problem that's simple enough for anyone to use and understand. A quote that I've often appreciated is this one from Brian Kernighan (the "K" of "K&R C", as I'm sure you and your engineers recognize):
> "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
I like to look at this, substituting the "you" who has to debug the problem in the present moment with an unknown engineer 5 years in the future with a non-working thing picking up the scraps of your work from today... How much smarter and more familiar with the problem do they have to be to figure out why your code isn't working anymore? Will such a person exist?
If this is partially an ego/respect problem, as it stereotypically often is, they'll hopefully recognize that someone 2x smarter than them probably will not be available. Another frequent stereotype of these engineers is that their creative appetite prefers building to maintaining, if you force them to maintain their creations because no one else understands or can read what they did, you may be able to encourage them to document, format, and design their code in ways that they will hope will reduce the amount of time spent on support down the road.
I work with a lot of people like this, and the key is to bring them to the realization that making a system objectively more featureful or capable does not necessarily make it objectively better: simplicity has value too. One of the key attributes of an embedded system is its longevity. If they want to make something complicated and they're the only person who will ever need to debug or understand it, that's fine, they can make it as complex as they like. But if you need a bus factor greater than 1, or work with other people, they need to design it with other people using it in mind.
Any engineer can make a complicated thing to solve a complicated problem. But the mark of a great engineer is that they can make a tool to solve that complicated problem that's simple enough for anyone to use and understand. A quote that I've often appreciated is this one from Brian Kernighan (the "K" of "K&R C", as I'm sure you and your engineers recognize):
> "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
I like to look at this, substituting the "you" who has to debug the problem in the present moment with an unknown engineer 5 years in the future with a non-working thing picking up the scraps of your work from today... How much smarter and more familiar with the problem do they have to be to figure out why your code isn't working anymore? Will such a person exist?
If this is partially an ego/respect problem, as it stereotypically often is, they'll hopefully recognize that someone 2x smarter than them probably will not be available. Another frequent stereotype of these engineers is that their creative appetite prefers building to maintaining, if you force them to maintain their creations because no one else understands or can read what they did, you may be able to encourage them to document, format, and design their code in ways that they will hope will reduce the amount of time spent on support down the road.