Don't be Fred. Freds get fired.
Eventually the "make a ticket for everything" scrum crowd wins out and it's now Fred's fault for refactoring without a ticket. Fred long ago learned that refactoring tickets always mysteriously sink to the bottom of the backlog, so he doesn't make them anymore.
TBH, the Freds I encountered are not really in any danger of getting fired. Because they were the only ones touching all parts of the codebase with their refactorings, they were pretty much walking bus factors.
Exactly this. Maybe Fred understands that if he creates a ticket to do a required refactor then it will never get prioritized and when things blow up in production 2 months from now it's his phone that's going to ring in the middle of the night.
You're spot on, though. I'm currently in a position where I refactor a lot. This is in a team that started with just me cobbling together a prototype, later with two other freelancers. We'd regularly completely reorganise our entire stack, because we were still figuring stuff out. Now it's a team with 7 developers, an actual PO, a separate scrum master and a designer, and I still love to refactor stuff while everybody else is building features. Another freelancer that's still left is our infra guru and he keeps tinkering with that instead of building features, but it's definitely helping the team.
You're right - it's important. But, guess what, most business people have no idea what refactoring means and no amount of explaining seems to get that through. They think it means developers get the equivalent of a paid holiday because of some preconceived notion they had at some other company they worked at.
Unless they wrote code in the last few years - I don't see people ever relating. It's just some abstract problem to them and you never get enough time to thoroughly explain how it all works.
Unfortunately, we're not like a factory. You can't make the retooling argument in the same way and see blatantly obvious results. It's more nebulous.
If someone out there figures it out - I'm sure we'd never have these discussions. They'd say, "Oh, why don't you just use the bradlys argument? He wrote it up on HN some years back and this refactoring discussion has been solved ever since."
"You can go fast when you're rapidly prototyping something that doesn't have to go to production, doesn't have to support thousands of users, is allowed to fall over at any time, and doesn't need to be maintained. You can also go fast when you're working on a well-designed system that is designed to support what you're trying to do. But the moment you start making it do something it wasn't originally designed to do, you slow down, and you risk turning the code into a mess that will slow you down even further in the future. If you want to go fast, let us refactor it now, so it will support the things we want to use it for."
And if they don't get that, maybe they shouldn't be in a position to make decisions about this sort of thing. Though I guess they won't respond well to you telling them that.
As you mention, they don't respond well to telling them that. Their own managers also don't like the implication that they made a mistake in whom to promote. Since everyone wants to protect their own career, nobody will ever step down or revert such a decision, with predictable results for overall product quality.
Be Fred. Get fired.
I hate to admit it, but I'm a Fred. Extrinsic motivation doesn't work well for me.
Yeah, I need to make some money I guess, but I'll make some pretty hefty compromises re: pay and benefits if it means working with an interesting stack or on an interesting problem because intrinsically motivated work is far higher quality for me than extrinsically motivated work.
A common pattern in my career is that my work stands out in some way that causes me to get pulled out of the main grind--and put on some fun special project.
As long as the value you're providing by being a Fred is greater than the value of the job you were hired to do, I find that they'll find ways to keep you around.
I do feel like a Jerk sometimes because I end up getting what feels like a promotion for doing my job poorly, while those doing it well have to stay and keep doing it, but when I buckle down and keep my nose to the grindstone I end up writing shitty code and letting my team down.
If Fred is otherwise hard working, there's probably a place for him nearby.
The art of management is to take that creative energy, skill, and passion and direct it towards generating value for the organization. Top tier teams happen in part because management flips this bit from zero to one for each team member, through leadership, coaching, decision making, and providing 'air cover.' You go to war with the army you have, and the best leaders turn people who would fail under average leaders into superstars.
If this is the person's only flaw, and they're otherwise a great team member, good person, and capable engineer, if they are ultimately fired, that is management's fault, not Fred's.
Don't be Fred's employer. Set up teams which build tools, maintain developer infrastructure, work across the company to improve code quality standards, and ease the burden of deploying services at scale.
I've been at three different employers on the equivalent of a tools team. It's a pleasure to have fellow developers as my customers, and I understand that my role is integral to not just success, but comfort and peace of mind.
I wonder if Fred accurately estimates his work to include all the quality, longevity and cost reduction work he does but just gets shouted down as pessimistic during their iteration planning?
Don't be in a job that fires Fred. That job is a ticking bomb.
In my exp re-factor happens when you add a new feature and it does not fit into the existing framework. Sort of a arch version of the rule of 3.