4 ms·

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

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?

mjsaah 8y ago
Uh, Dev A should take the time to understand Dev B's argument before writing it off as esoteric excuses.
ajdecon 8y ago
> 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. :)
debt 8y ago
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.
ashelmire 8y ago
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.
- user5994461 8y ago
  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.
logfromblammo 8y ago
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'.
user5994461 8y ago
>>> 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.
- stcredzero 8y ago
  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.

mjsaah 8y ago

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

ajdecon 8y ago

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

debt 8y ago

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.

ashelmire 8y ago

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.

user5994461 8y ago
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.

logfromblammo 8y ago

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'.

user5994461 8y ago

>>> 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.

stcredzero 8y ago
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.