"Unfortunately this tool doesn't exist for blb++, but we should still improve our coding style for this application. Is there another way to improve our correctness testing? If we allocate some time to improving unit testing, maybe we can do this refactor once we have X% coverage in these critical parts of the codebase."
I.e., acknowledge that both goals are valid, and look for alternate solutions to make incremental progress towards both. Finding middle ground is unlikely to be satisfying from either viewpoint. In this example, Dev A isn't getting a quick win from fixing the coding style right away, and Dev B needs to allocate some time to improving testing. But especially when working on big teams and projects, this kind of piece-wise progress is where I've seen most things get done.
This kind of solution might be pointed out by either Dev A or B, or they might need to bring in a fresh pair of eyes if they're both already frustrated. :)
Dev B gets laid off, and Dev A works until burnt out.
Game over. Everybody lost except management.
I was Dev A a couple of years ago. Don't be Dev A for too long.
Do you know that progress report and commit messages don't even have to match what was actually done or committed? The project is your playground.
Except that's wrong. The new style is not "better" at all. Replacing CamelCase with underscore_variables and forcing brackets on new lines make no practical differences.
All the time to rewrite hundreds of files was just churn.
RAII is tons better than older memory management styles in C++.
The newer styles of C++ initialization are tons better than the older ones, which seem to inevitably result in a dozen ad-hoc mini-initialization frameworks.
Replacing CamelCase with underscore_variables
That is indeed arbitrary and useless.
forcing brackets on new lines
Forcing brackets on new lines is useless. Mandating the use of brackets has been shown to be very useful for reducing bugs.
Cast:
Developer A, a younger developer who is recognized company-wide as an expert in the latest features of blb++.
Developer B, an older developer who maintains widely used legacy code in blb++ involved in about 80% of a billion dollar multinational's profits.
Dev A: Your group should change the coding style in this application to the new standard.
Dev B: Sure. But since we don't have good Unit Test coverage in this area, we shouldn't just go in and do it by hand. I need to guarantee correctness. I've done a change this big before using a syntax driven automated code rewrite tool, and one can guarantee correctness if the code structure allows it. If you know of such a tool for blb++, you can help me out and we can do it.
(Background for the reader: No such tool exists for blb++ which can guarantee correctness. Such tools do exist for other languages in Dev B's work experience.)
Later on, Dev A is grousing about how Dev B is just coming up with esoteric excuses to do nothing. She's kind of put off. Dev B is put off, because he's kind of been accused of making stuff up, even though he's talking from a particularly interesting and valuable part of his work experience.
Dev A is correct, in that the new coding style is better, more efficient, and would even prevent mistakes going forwards. Dev B is correct, in that he really needs to guarantee correctness, especially if he's going to make a change that big which has no visible benefit to stakeholders. What's the takeaway?