[closeparen]

Learning new skills is easy enough, what kills me is the enormous manpower invested in churning working code.

Easily 30% of my company's total engineering effort is just treading water, migrating from a deprecated platform to another one that will be deprecated by the time the migration is complete. Typically because the original team's standard 18-month tenure has elapsed and the new guy was under-leveled at hiring so he needs impact for promotion.

It's a great disservice to our field that people so deep in the stack are so comfortable changing their minds all the time. The Python 2.7 thing feels like the Library of Alexandria. Burning down mountains of perfectly good working code just because we can.

Backwards compatibility is tragically underrated.

[zelly]

Backwards compatibility causes a lot of evil. I would prefer that breaking changes come with automated tools to migrate. Sometimes bad decisions get made, and we shouldn't have to carry the burden of that forever out of laziness/stubbornness. What ends up happening is the opposite of what you wanted, because after enough backwards compatibility debt adds up, someone starts a fresh competitor that takes over.

[gridlockd]

> I would prefer that breaking changes come with automated tools to migrate.

The hard part of the migration isn't that you can't automate it. The hard part is that you can't automate verifying that it didn't break anything. So you rather stick to what you have.

> Sometimes bad decisions get made, and we shouldn't have to carry the burden of that forever out of laziness/stubbornness.

Here's the deal, Mr. Developer who wants to change everything because the old stuff is somehow bad and the new stuff surely is better: I almost certainly have better use for the money than to spend it on migrating the code. The old code will keep working. That's not laziness, it's prudence.

Developers always exaggerate the benefit of rewriting stuff and changing things around. I understand why, you'd rather arrange the code you work with to your taste than whatever horrible stuff is there already. The problem is that every other developer feels the same way, but with a different taste.

For instance, some people hate object oriented programming, some people think procedural programming is somehow bad, some people believe functional programming is generally good. I believe the best programming is the one you can just stop arguing about and solve the damn problem with, sooner rather than later.

> What ends up happening is the opposite of what you wanted, because after enough backwards compatibility debt adds up, someone starts a fresh competitor that takes over.

That's not true at all in the vast majority of businesses cases. The benefit of the migration would have to be so spectacularly high, it would have to offset its cost. Again, this almost never happens.

Whenever you break compatibility, you burn good will. Whenever you break compatibility, you give me an opportunity to switch to your competitor. If I have to migrate, I might as well migrate to something else.

[closeparen]

When code is hard to maintain, extend, or debug we should absolutely refactor it. Even if something is fine but can be expressed better using a feature from the language's new backwards-compatible release, go for it.

The tragedy is mandatory, all-out migration for code that was already high quality, and just happened to be written for an older stack.

[gridlockd]

All code is "hard to maintain, extend and debug" to the person who didn't write it and therefore doesn't like working with it. Developers like to exaggerate this all the time, because they want to maximize their own comfort.

Even if developers were able to objectively asses that code is hard to maintain/extend/debug, that doesn't mean changing it is the right business decision. It may or may not be. From a pure efficiency standpoint, it may well be a net loss. From a developer psychology standpoint, it may be worthwhile.

You also can do a lot of refactoring without breaking a lot of code, especially if you didn't buy into the idea of writing tiny functions and unit tests for every piece of functionality.

[closeparen]

If you’re stuck working with people who think they are the only ones ever to have written good code, I’m sorry. That must be unpleasant. But please don’t take that out on everyone else who merely gives a shit about the quality of their work.

Most of the code I refactor is my own from a few years ago, btw. Usually because I learned new information, past choices turned out to have regrettable unforeseen consequences, etc.

But we have learned to be really careful about public APIs. Implementations may change, interfaces are forever.

[gridlockd]

> If you’re stuck working with people who think they are the only ones ever to have written good code, I’m sorry.

I didn't say that.

> Usually because I learned new information, past choices turned out to have regrettable unforeseen consequences, etc.

Indeed, that "awful" code may have been written by the same developer from one or two years ago and now they're not comfortable with it anymore either.

Of course I'm being a bit hyperbolic, but what I'm saying is basically true and applies to pretty much everyone.

It's not all bad either, without some push towards renewal, we would be stuck with old ideas forever. The key point is that permanent renewal has a cost that the business must carry. Sometimes no renewal at all is the right business decision.

[TsomArp]

It doesn't matter if it is easy. If you have to waste time because the language-of-the-week came, which multiplies for N number of devs, is still a huge waste of time.