I think you are offering bad options: refactoring is something that comes with any new work. You don't have to justify it, but include it in your estimates.
Obviously, the risk here is that you include non-neccessary refactoring work in it, and then people stop trusting you.
And finally, there is a hack-it-together approach, but I always try to keep that outside the core product to make it clear this is throwaway effort (if you can have another deployment, that's ideal).
But honestly, it is engineers job to find that hard to reach balance: keep improving the code, and keep delivering value.
That's the hard part of software engineering, and we should all embrace it.
> refactoring is something that comes with any new work. You don't have to justify it, but include it in your estimates.
Sometimes it's too much work to do ad hoc. Oftentimes people won't go out of their way to refactor. Having the fair discussion can make it real and important.
If the team can't talk about refactoring, it's an unhealthy team. Managers who want to act like maintenance of a project isn't something that should ever be their concern don't deserve a paycheck.
> But honestly, it is engineers job to find that hard to reach balance
This attitude is bullshit. It's everyone's job. High level balance is more of a concern for management. Low level balance is the more of a concern for engineers. High and low level balances can work for or against each other. Management that just pushes their responsibilities down the hierarchy aren't pulling their weight.
Sure, it is everyone's job and they should certainly openly talk about it, but no manager can go and do it for an engineer.
A great engineer can find an incremental value with any refactoring they do: otherwise, they are extremely likely to refactor for the wrong future. I've seen this play out a number of times.
And the root cause is always exactly the same: engineers can't design code for the future that's not here today or at most, tomorrow. When they think they've done it, a new future comes and that code is even harder to refactor because it prematurely catered to cases that never materialized.
But that's exactly why managers need to understand and accept that refactoring is software engineering, and engineers need to do it continuously and keep delivering value while they do it.
And while CTOs, Eng Directors, architects and technical leaders might be "managers" in a sense, to me they are still all engineers, and they are the ones ensuring technical direction enables a healthy project while satisfying business goals.
Non-technical managers are there to bring clarity to business requirements, but they don't need to know exactly how sustainable technical excellence (or at least health) is achieved, the same way engineers don't need to know how user research or user testing that proves something works or not, is performed.
Obviously, the risk here is that you include non-neccessary refactoring work in it, and then people stop trusting you.
And finally, there is a hack-it-together approach, but I always try to keep that outside the core product to make it clear this is throwaway effort (if you can have another deployment, that's ideal).
But honestly, it is engineers job to find that hard to reach balance: keep improving the code, and keep delivering value.
That's the hard part of software engineering, and we should all embrace it.