The technical term for that is "a Lava Flow".

The code melts and changes for awhile... and then congeals into unchanging rock again.

I'm using that term from now on. :)

One project I worked on had almost a half dozen "lava flows" in the JavaScript alone... I had a hard time convincing folks we could rewrite it using ASTs because all the rewrites scared folks away from any further rewrites!

The best (well, worst, really) part is when it ends in a state where the parts are almost right, but not quite. The result is, quote one of my coworkers, "We ended up with the architecture that is so flexible that we can't change a single bloody thing in it! What the hell!" The whole is flexible, but this flexibility is pointless: you can make the parts behave differently, but there is only one behaviour that is actually useful; you can combine things together differently, but there are at most two combinations that do things in a useful way; etc.

Sounds like the effects of temporal coupling, or "settism and gettism", or other principles, which are violated. People are blinded nowaways too much by SOLID, and forget about the remaining 20 principles.

I've seen that applied to long running legacy projects. This is how they did things back in 2008. Here someone discovered an orm library. Now here, they started to try to introduce some microservice event driven architectural pattern that was all the rage in the blogs that year....

I think we can all agree that the dev who starts a big refactor and then drops it when it's half-done is a terrible human being

I don't agree. Big refactors are _hard_. They usually require levels of sustained focus at multiple layers of abstraction, and its really easy to get exhausted/burnt out or be forced to switch gears in the middle.

People learn by doing. And after a few such messes, the dev will learn how to do smaller refactors.

That's me. I want to finish my refactor but business requirements have me pumping out new epics.

I chip away at it in my down time but it's no longer prioritized.

I find in this line of work, you will always seek to find ways to balance business/market needs vs. being a paragon of programming.

There's not always time to finish it properly, but there's often a good stopping point halfway. When there's a lot that needs refactoring, I start with one specific thing, and leave the rest for now, so the piece I've bitten off is still small enough that it can be wrapped up in a reasonable amount of time. And the rest will have to wait.

In my current project, there are piece of code that I've wanted to remove for months now. I was working on refactoring it out completely, but there's one place that still uses it, and that wasn't so easy to fix as all the other places where it had become unnecessary. It still needs to be done, but there hasn't been any time. Or urgency, really. But it's still there, taking up space in my head.

And how does the team feel about it?

They also want to get rid of the old code, but they're not removing it. One of them also has a tendency to interesting structural solutions, though he tends to do it more by adding them than by rewriting what was already there, which has the advantage that it doesn't disrupt the old code that others are working on, and the corresponding disadvantage that the old code survives.