Just my 2 cents, as I have been on the other side of the table: - It could be that you misunderstood the argument. Maybe the engineer wanted to avoid the old '

Just my 2 cents, as I have been on the other side of the table: - It could be that you misunderstood the argument. Maybe the engineer wanted to avoid the old 'static global global' structures, which are still omnipresent in embedded C code, and which is followed by especially bad engineers. It's not about memory at runtime here; it's more about encapsulation, state and testability - If that is the case then let the engineer do it. Code quality can be measured by how easy it is to remove a feature - I've went into numerous turf wars about code style. I lost all of them, even if I won some battles. At one company, they were paying one full time engineer to manually reformat the team's code. Don't play this game. Slap on astyle or clang-format. Enforce it. End all discussions with "Then you change the style guide and check with other projects". You win in either case. - Don't ever argue with people who organise their code in neat tables with tabs and spaces - Don't you have a product to ship? Make that clear to everybody, break it top down, and let the engineers fix that stuff. - Remember, they are doing the work, you are just organising. Why should the code be easy for you to read? - Maybe that complexity just exists for you, not for them. An isolated system may be as complex as it wants to be - I'm not always right. And other people as well. We need room for mistakes. That lets people grow. I did a lot of mistakes, and I will do more. So even if I know for a 100% that my colleague has chosen a bad path with bad complexity and a lot of work further down the road, I still let him walk that path. He needs freedom. All I can do is support him and protect the rest against the fallout. Other people offer me that freedom as well.