Interesting. For these kind of upgrades of doom, I try to cherrypick changes that can be applied on main as soon as possible, but I haven’t done anything so drastic as deleting everything and starting over from main.
The “delete everything” approach doesn’t work for me - I frequently get pulled into more urgent tasks for a few days or even weeks at a time, so relying on memory on how to do things isn’t feasible.
That said, I do frequently prototype/explore a difficult large change, keep the prototype in a branch for reference, then start over for a clean re-implementation based on the latest main branch. The new implementation is done with as small changes as possible which can safely be applied individually, as in the article’s methodology.
Occasionally I’ll copy code snippets from the prototype when the quality is good enough though, or I’ll copy a whole newly added function and use it as a basis for tidying up into something production ready.
Yeah, I usually try and avoid throwing all the changes away, and instead identify a small change that’s itself atomic, and stash the rest while I ensure those changes build, &c.
For better or worse, it usually depends on which option (out of stashing vs. deleting) would be less annoying.
I think it depends on your tolerance for keeping a stack of unfinished change sets under control until you (finally) reach a leaf-node and can start moving back up the the dependency graph. For me, it always seems like a good idea to just keep digging, until it no longer does, and then I’m filled with regret. So while it doesn’t (yet?) feel natural to me, I try to always consider this technique in the early stages of a change.
Another thing that’s mentioned in the book and which I’ve found very helpful, is to use a Mikado graph for larger-scale, longer-term refactoring. The kind of thing that touches multiple services or that you need to pick away at over a long time frame. This helps me:
keep the dependencies straight without having to rely on memory
chip away at technical debt in a structured way (because nobody wants to pay to address technical debt in one big go)
get a sense of completion by checking tangible things off a list along the way
Interesting. For these kind of upgrades of doom, I try to cherrypick changes that can be applied on main as soon as possible, but I haven’t done anything so drastic as deleting everything and starting over from main.
The “delete everything” approach doesn’t work for me - I frequently get pulled into more urgent tasks for a few days or even weeks at a time, so relying on memory on how to do things isn’t feasible.
That said, I do frequently prototype/explore a difficult large change, keep the prototype in a branch for reference, then start over for a clean re-implementation based on the latest main branch. The new implementation is done with as small changes as possible which can safely be applied individually, as in the article’s methodology.
Occasionally I’ll copy code snippets from the prototype when the quality is good enough though, or I’ll copy a whole newly added function and use it as a basis for tidying up into something production ready.
Yeah, I usually try and avoid throwing all the changes away, and instead identify a small change that’s itself atomic, and stash the rest while I ensure those changes build, &c. For better or worse, it usually depends on which option (out of stashing vs. deleting) would be less annoying.
I think it depends on your tolerance for keeping a stack of unfinished change sets under control until you (finally) reach a leaf-node and can start moving back up the the dependency graph. For me, it always seems like a good idea to just keep digging, until it no longer does, and then I’m filled with regret. So while it doesn’t (yet?) feel natural to me, I try to always consider this technique in the early stages of a change.
Another thing that’s mentioned in the book and which I’ve found very helpful, is to use a Mikado graph for larger-scale, longer-term refactoring. The kind of thing that touches multiple services or that you need to pick away at over a long time frame. This helps me: