3 ms·

Good points. Those are the main problems I've run into. One is pretty much having to ask others to trust you that what you're doing is worthwhile (because big r

by dmos62 6y ago

Good points. Those are the main problems I've run into. One is pretty much having to ask others to trust you that what you're doing is worthwhile (because big refactors are exploratory, in my experience). The other is an extension of that where if the refactor is larger others will have to come in for sizable PR reviews. In the end, the problem is that refactors cost money and time. Essentially, they are humble rewrites. The good part is that a big refactor opens doors in terms of where you can take that system and reduces maintainance costs, but those are long term gains. A short term loss, but a long term gain. I'd like to have a better concept of how to make that sell. I think some organizations will be more inclined to that type of investment than others.

jka 6y ago
That's a thoughtful approach, but if I were a (technical) business owner I'd still be skeptical about those large refactors. As a fellow engineer I'd appreciate them, but for our overall organizational success I might still wonder if they were the best use of time -- especially because large refactors/rewrites can be risky. If you started by developing test coverage (that would remain constant throughout the refactor) I think I'd find that an easier sell as both a tech business owner and a fellow engineer. Another angle to consider could be handling 'known' technical debt as feature teams emit it. For example, a feature team might be aware that there are some negative aspects to their implementation, but they may have other high-priority tasks to handle. Catching those "debt outputs" (perhaps detected during code review) could be a continuous task for a role like this. The problem in that case would be alignment of incentives: how do you ensure that the feature team doesn't just take the easiest possible implementation and claim that all the downsides are just technical debt to be cleaned up by another team.

by dmos62 6y ago

jka 6y ago

That's a thoughtful approach, but if I were a (technical) business owner I'd still be skeptical about those large refactors. As a fellow engineer I'd appreciate them, but for our overall organizational success I might still wonder if they were the best use of time -- especially because large refactors/rewrites can be risky. If you started by developing test coverage (that would remain constant throughout the refactor) I think I'd find that an easier sell as both a tech business owner and a fellow engineer. Another angle to consider could be handling 'known' technical debt as feature teams emit it. For example, a feature team might be aware that there are some negative aspects to their implementation, but they may have other high-priority tasks to handle. Catching those "debt outputs" (perhaps detected during code review) could be a continuous task for a role like this. The problem in that case would be alignment of incentives: how do you ensure that the feature team doesn't just take the easiest possible implementation and claim that all the downsides are just technical debt to be cleaned up by another team.