I think there can be many rational reasons for 're-writes' that preclude any assumptions about 'bad code'.
New infrastructure requirements, languages, performance considerations, markets, customers etc. etc. - they all change.
An expanding and adaptive business will likely have to refactor code that was 100% perfect in 'context ABC' because they have some new 'context XYZ'.
There are so many examples to think of.
When they went from one datacenter to many, whenever they replace the hardware architecture in their datacenters or change newtworking configurations. When they decided to integrate G+ into everything. When they decide on using a new common UI framework.
The 'roll on' effects may necessitate refactoring of other code.
And this is not including more opportunistic things in a given area.
Maybe they started doing some stuff in 'Go' and wanted to refactor other modules into 'Go' for greater maintainability?
And I don't think anyone will be 'blindly copying' Google's processes.
New infrastructure requirements, languages, performance considerations, markets, customers etc. etc. - they all change.
An expanding and adaptive business will likely have to refactor code that was 100% perfect in 'context ABC' because they have some new 'context XYZ'.
There are so many examples to think of.
When they went from one datacenter to many, whenever they replace the hardware architecture in their datacenters or change newtworking configurations. When they decided to integrate G+ into everything. When they decide on using a new common UI framework.
The 'roll on' effects may necessitate refactoring of other code.
And this is not including more opportunistic things in a given area.
Maybe they started doing some stuff in 'Go' and wanted to refactor other modules into 'Go' for greater maintainability?
And I don't think anyone will be 'blindly copying' Google's processes.