Comment by stcredzero | Hacker News Reader

Comment by stcredzero | Hacker News Reader

How everyone can be right, but everyone gets annoyed anyways.

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?

> What's the takeaway?

"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. :)

Devs A and B collude to convince manager M to fund development of the nonexistent tool. They use it to update the code base with confidence. Dev A supports the new code. Dev B supports the tool. Dev B and sales S team up to sell licenses and migration support to other companies that use blb++. M pockets a nice bonus, and gives A and B 2.5% raises. When the corporate well runs dry, S moves on to something else, and B open-sources the tool. A and B get invited to blb++ conferences to earn peer recognition and prestige. They co-author a book, and then pocket a bigger windfall than M's bonus. A and B get hired by another company to support a fork of their tool. Then blb++ loses popularity, B goes into consulting, and A becomes the B' to someone else's A'.

Dev A wins because management is trying to fire Dev B. Dev A works longer hours and is paid less because they're young and stupid and don't have a family. Dev A is better for business.

Dev B gets laid off, and Dev A works until burnt out.

Game over. Everybody lost except management.

Dev A is a junior developer that doesn't understand the time and opportunity cost of rewrites. Or that projects and managers don't care about style, they want new features and stability. Doing things better going forward is great. Going back to change legacy code for style? Frankly, that's a big waste of time, and management will not look fondly on your lack of visible or impactful progress.

I was Dev A a couple of years ago. Don't be Dev A for too long.

It can be done in a way that show massive visible progress and impact. Just have to fill plenty of tickets for doing plenty of changes. Adding new features that are already present, sometimes renaming the file that had them if necessary. Fixing bugs, possibly freshly reintroduced because the existing fix was purposefully ignored or removed.

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.

Uh, Dev A should take the time to understand Dev B's argument before writing it off as esoteric excuses.

>>> the new coding style is better, more efficient, and would even prevent mistakes going forwards.

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.

Except that's wrong. The new style is not "better" at all.

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.

Reply on news.ycombinator.com