3 ms·

It's about time that we did have (and celebrate) this kind of role; it'd be something like a maintainer position, except - depending on the organization - perha

by jka 6y ago

It's about time that we did have (and celebrate) this kind of role; it'd be something like a maintainer position, except - depending on the organization - perhaps a bit more focused on cleanup. A couple of thoughts: - If you work on open source projects, you can create and tweak this role for yourself by finding needful tasks in upstream projects; just be careful to validate your approach to make sure your changes are likely to be accepted - If this were a role within a salaried organization, you'd ideally want a way to show -- or a shared consensus -- that the work involved is worthwhile and producing value. How would we do that for software projects?

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 jka 6y ago

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.