Rearchitecting Software
When rearchitecting the world, do it along with the rest of the team.
I recently had the misfortune of doing a 4 month long project to make major changes to the underlying architecture of a project 6 other developers were also actively working on. I did this on a development branch, outside the scope of development the rest of the team was doing. On at least three occasions I had to spend a day to a week merging in their semi-major changes (week to month long projects) and making sure everything still worked in my new world.
That sucked. I didn't understand what their changes were supposed to do, and reintegrating them didn't always work right away, and they had no visibility into how they should code to be more compatible with what I was doing.
I did too much of my reorganization as if no one else was working on the code base (which had been true just a few months earlier).
In one place, code from four different files became gathered in one new function. But because of the scope and flow control of this new code site, it wound up being a copy-and-paste job, and then when people made changes to the old code, those changes had to be manually merged into the new code. Uf.
I now think the answer should have been that I do all the reorganizing I could in the main development branch, making my changes visible to others, lifting code into functions that could be called from either the old framework or the new one.
I think this wasn't done because management insisted (and it seemed kinda reasonable) that experimental code shouldn't be committed to the main development branch where it could get in the way of other programmers or even moved out to production code (as a web service we could deploy every week if we wanted).
I think this was actually wrong.
Big changes should be made where they effect everyone, but they should be made in lots of small steps.
I tried to do this in one place early on, and got push back and kinda told not to do that again.
I lifted the middle of one function out into a new function, because that was the part I needed to call from new code.
It was functionally no change to existing code, and that was received as a kinda bad thing. Don't change what works; if it ain't broke, don't fix it.
And yet I was undertaking a large project to change a lot of things that needed changing.
So, there was a little mismanagement, and a little messy coding, and I'm not sure exactly what the moral of this cautionary tale is, except that next time I'm making major architectural changes to software, I want everyone to see my changes all the time so that we're not stepping on each other.