I find the article quite presumptive in the sense that it presumes everyone has the same definition for "gold plated", etc. That, coupled with the With the remedy of "give the guy something else to do" makes me think that the writer is on the opposite of the spectrum which could be characterized as "throw stuff at the wall and see what sticks."

I know this seems pejorative on some level, but I'm trying to paint a contrast here between sensibilities. I think it is worth considering that one person's urgent and long-needed reduction in technical debt is another person's over-engineered. It often comes down to whether the person passing judgement has the awareness of how everything fits together and thus can benefit from a structural tune-up. It could also depend on how many systems and code bases they have had to maintain.

I mean, on balance, we have a really bad track record as an industry of building unmaintainable code bases. Most developers are working on the things they find enjoyable with less regard for making it work well for other developers. I think that the author's remedy of splitting these responsibilities out into separate roles is an indicator of the overall problem. It shouldn't have to be framed in that way to make it palatable to the average developer.

As a developer, you should always want to make the code you work on work well for others, and that includes refactoring on occasion. If you find yourself in a posture where you are always "innovating the new fun stuff" while others are seemingly dragging you down with making it actually manageable, it's time to slow down enough to realize what this means to your team.

By not taking care of your own code so that your other developers find it manageable, you've turned them into your cleanup crew. You need to thank them for being "That coworker" who you find "gold plater, or unproductive, or slow", and perhaps stop building prototypes and calling them done.

Just some food for thought.

Don't forget halfway refactoring. The worst case I've ever had was a project with 3 completely different and incompatible ways of accomplishing everything. Different packaging schemes, different DAO designs, different UI framework/libraries. The worst!

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.

Similar experience and totally agree. How often do people go out of their way to improve a severely limiting code base? Not enough.

Often it's because they are being pressured by leadership not to. Leadership's bonuses and promotions are dependent on developers delivering value NOW.

Some of that is on developers, famous for overpromising and under-delivering and generally not managing expectations. There is a real skill to effectively explaining a job’s requirements to non-developers, and it’s something I think a lot of us suck hard at.

Plenty of it is also on managers who simply aren’t competent to manage, of which there is a tragic abundance. If that really bothers you, move up to management and start doing the job better or go find a new job. Otherwise, not your circus, not your monkeys.† Just make sure to keep your papertrail.

--

† Whereas the liabilities for screwing with production code outside your scope of work def should be. Though again, that assumes a management that actually understands what’s going on in its own shop, and isn’t just running around with its hair on fire 24/7.

Doesn't leadership hold a lot of stock?

Most productive refactoring carries forward from a more effectively designed data model. There can be value in pushing code around but often a lot of that can be subjective, which this thread has discussed.

Even big corporations are open to refactoring when you put it in the context of data integrity and consistency (foreign keys), because data inconsistency causes tickets which cause churn which is a number the CEO reports to the board.

Mostly agree but I think the distinction is not always clear between data model changes and changes to application-tier logic. In most cases you can do a particular refactor either way and you have to figure out what is the best way to achieve it. Just pushing code around is usually not tremendously valuable but it's also not particularly costly.

This is what I've seen too. Higher pressure to get features out. Then the code gets worse and worse over time. Development gets slower and pressure gets more intense. Then customer gets pissed off and fault lands on the Devs.

Yep, but there you are refactoring as a necessary prerequisite to achieving a clearly-defined end goal. That’s part of the development roadmap and should be planned and budgeted accordingly. When building a house, a professional builder knows to dig out and pour a solid foundation, so that by the time they get to tiling the roof the walls beneath it aren’t already sinking and tearing apart.

That’s very different to just dicking with the company codebase for one’s personal amusement. That’s the bloke with the dozen rusted automobile shells sitting on bricks in his front yard, while he’s in his shed “busy working” on number thirteen. He’s not productive, he’s just playing with himself. And making the whole place look like trash while he’s at it.

Right, of course dicking around with the codebase for personal amusement is bad and a poor use of time. But I think refactoring doesn't necessarily have to be achieving a clearly defined end goal to be useful and appropriate. Primary because product development itself doesn't have a clearly defined end goal. It's an iterative process where the end goal can change as you discover new information. To follow on your example, if I'm building a two story house and pour a foundation to support that but then the foreman comes along and says "actually we need to build a ten story office building on the same footprint" then you absolutely should start over and pour a new foundation. If you have a well-defined spec to begin with and it doesn't change and you STILL need to do a bunch of refactoring along the way then you probably did something wrong. But in my experience that is almost never the case. Refactoring happens because the requirements change and assumptions you made are no longer valid.