In my experience, the moment that creates the greatest amount of legacy code is when you have a team who's project grows large enough that the team splits. At that point, many modules and projects are divided, but anything not explicitly considered ends up as untouchable spaghetti. Most of the time, it's because the code is working, so why put in the work to split it up, just because of a team change? Of course, it stays working, and if needed, you can get the original gang back together to fix it. Until it's been 2 years, and half of them quit, and the others don't remember it quite well enough...
Considering organizational change as the primary driver of system structure change seems like a powerful way of thinking.
Comments
I really like this.
In my experience, the moment that creates the greatest amount of legacy code is when you have a team who's project grows large enough that the team splits. At that point, many modules and projects are divided, but anything not explicitly considered ends up as untouchable spaghetti. Most of the time, it's because the code is working, so why put in the work to split it up, just because of a team change? Of course, it stays working, and if needed, you can get the original gang back together to fix it. Until it's been 2 years, and half of them quit, and the others don't remember it quite well enough...
Considering organizational change as the primary driver of system structure change seems like a powerful way of thinking.
The worst parts of the code last the longest. The best parts of the code change all the time.
A great example of the Lindy Effect.[1] Something which took me too long to actually remember the name of...
[1] https://en.wikipedia.org/wiki/Lindy_effect