I once spent 8 months merging a codebase with almost every single function duplicated three times, and all that was required for each (most of the time) was another parameter, one conditional in function, and all 3 could be merged.

So I did that! And at the same time cleaned up the code, fixed bugs, and adding required new functionality, and all while merging in constant change from the main codebase.

After reducing a 1M line codebase to 280k lines, when almost done, after that 8 months, I was asked "how much longer".

My response of "a month for testing" was apparently too long for the new manager, who turfed all those fixes, including the new functionality.

And I wasn't even behind schedule, I was ahead.

Once abandoned, everyone just copy and pasted my changes... in triplicate, into the old codebase.

Which took 3 months, instead of 1.

Bah. A year of my life wasted.

Spending 8 months when the business value at the end was mostly improved velocity doesn't sound likely to be a good tradeoff, especially if this is done as a big bang effort which either succeeds holistically or fails. You might have better success in the future by finding ways to integrate maintenance improvements incrementally.

> finding ways to integrate maintenance improvements incrementally

To be fair, it's possible bureaucratic process got in the way. If their commit / deployment process didn't allow for any changes to hit the production branch until it was "finished" then there wasn't really an opportunity for them to increment.

That seems likely considering "the new manager, who turfed all those fixes, including the new functionality" suggests other organizational problems. If one month is too long for the new manager, the new manager's goal seems to be to "do things" rather than to "solve problems".

This kind of refactoring also greatly improves robustness and stability, very worthy if the company values those qualities in their product.

This illustrates the problem with this 'business value at all costs' perspective. Improved velocity is not the only or even primary takeaway from consolidating 3 mostly identical codebases into 1. There are so many benefits that I struggle to think of a decent justification for leaving triplicated codebases in play, based on what GP has described.

This is a great cautionary tale about what happens if you don’t continuously integrate changes in an incremental fashion.

It's a great cautionary tale of management dumbassery. (yes I am still bitter)

Did you maintain a separate branch for 8 months?

Yes, and merged in all edits.

Others are discussing incremental changes, that doesn't work well when underlying frameworks have significant breaking changes.

No everyone, I didn't choose the framework. No, I couldn't change it. No, I didn't choose the path.

While I know people are trying to help, suggestions starting with "you should have" aren't very helpful here.

> suggestions starting with "you should have" aren't very helpful here

But they might be helpful to others.

There are ways to do these large refactorings that allow for incremental changes, never checking in a commit that breaks the build and where tests are passing at each stage. Your experience doesn't sound great and I'm sorry that happened to you, but I just wanted to add this to say that it's not necessarily personal.

I appreciate what you're saying here, and that your comment is more tactful than others, but I also see why the the op would be frustrated with the responses.

The responses to far, to my subjective reading, imply that the OP did something stupid and that's why they were in that situation. Again, it's just a personal interpretation, but I don't think it's a far-fetched one, and I don't think we have the context to make that assumption.

I agree that it can be useful to highlight the possible pitfalls to readers, but it's my opinion that it could be done in a more empathetic and tactful way that highlights our collective lack of context while still providing general advice to readers. I also think it would tend to lead to a more nuanced and useful conversation for the same readers.

Yeah, I agree completely. Thanks for taking the time to share your thoughts and to contribute to this community, that we all hold so dear, with a soft touch.

Just another time where prepending your words with 'IMO' would help much.

My condolences. Looking on the bright side, your manager laid their cards on the table and revealed their competence pretty quickly.

As someone who gets mired in details, I can understand how it happens. It's so much easier to focus on something you can control and fix.

Not excusing or defending it, just trying to serve up a reason why it happens.