> It makes one wonder what their internal employee incentives are and if they're problematic.
not a very strong one until recently. They implemented the FAANG esque "levels" in late 2021. Promotion lines weren't too atypical from FAANG, but the new system was not around long enough to cause the problems people complain about today.
The biggest issue IME was that teams were isolated. Maybe DOTS should have talked more with strongly integrating HDRP/URP into its workflow, but DOTS was busy getting off the ground itself. HDRP and URP are two very different teams and they were trying to solve very different problems. Perhaps that was a bad move for the people it was serving, who'd want to have the flexibility to migrate to/from HDRP and URP. There weren't really much product management that was trying to make the engine cohesive, so you end up with a rendering core and a bunch of different plugins with different philosophies and whatnot.
>I feel like wanting to start-a-new is a common tech problem, where there are problems and everyone wants to just reboot to "fix" it rather than fixing it head-on inc. backwards compatibility headaches.
to some extent, yes. I think the one huge downside of Unity compared to modern companies is its antiquated CI/CD. Getting changes into the core c++ engine took 10x longer than it really needed to. iterations on repo builds were slow because Unity simply didn't cough out the money for proper server farms, and the interface to interact with the status of PRs felt like it was from 2005. Much of DOTS was iterated upon separately on with modern Jira/Github/etc. pipelines and the DOTS repo was very lean (and it was public too... until it wasn't. I think they moved it in 2022?), moving to make a change to the core engine was like traveling back in time 15 years ago.
Legacy code is a pain as is. And Unity definitely needed to revamp some non-feature workflows before it could really dig into the core Unity engine issues.