(Hint: Refactoring is usually an inefficient way to write a second system, with all of the downsides of the second system effect.)
Sounds like you are saying that refactoring is usually incompetently done to me.
Sounds like you are saying that refactoring is usually incompetently done to me.
Not at all intended on my part. Nor would I say it is usually what went wrong.
The primary root cause is an underestimation of the true complexity of the problem. The details of which only start to become apparent after you've begun the rewrite.
An inevitable secondary cause is organizational pressures to add features to the rewrite. This happens after frustration builds because other departments have been unable to get features into the legacy code. I can't fault developers for lack of skill in managing these organizational pressures. That skill is not a core competency for developers, but it generally is for the people who are trying to get their agendas into the development roadmap.
If there is any additional challenge from the lack of skill of the developers, then you had much bigger problems from the start.
Refactoring is usually the modification of existing code while maintaining existing functionality in order to make the code easier to maintain and reason about for future developers.
Furthermore, if you're given points for refactoring (as you should be) your velocity is very unlikely to go down in my opinion. I will say that many teams and managers do not do this, but that's because they're poor managers.
If you have tests in place you will cause fewer bugs by refactoring. If you don't you will still create a few bugs as you refactor. But imo, fixing the bugs created by refactoring is just... part of refactoring. If that means the task requires an even higher number of points, so be it.
As a manager, there's no point in forcing the team to accept a reality they know isn't possible. It's not beneficial for anyone.
Small refactors happen all the time.