Microsoft has a similar problem where nobody gets promoted from fixing bugs or maintaining stuff, everyone gets rewarded for new innovative [thing] so every two-three years there's a completely new UI framework or similar.
Although 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.
Is there any big (or even medium-sized) company where this isn't true? I feel like it's just a rule of corporate culture that flashy overpromising projects get you promoted and regularly doing important but mundane and hard-to-measure things gets you PIP'd.
At another job, at a financial firm I got a big bonus after I went live on November 28th with an upgrade that let a system 10x their max throughput, and scaled linearly instead of being completely stuck. at their 1x. Median number of requests per second received in dec 1st? 1.8x... the system would have failed under load, causing significant losses to the company.
Prevention is underrated, but firefighting heroics are so well regarded that sometimes it might even be worthwhile to be the arsonist
So I wonder: do the same dynamics appear in any non-software companies? If not, why not? If yes, have they already found a way to solve them?
A long history of blood, lawsuits, and regulations.
Preventing a building from collapsing is done ahead of time, because buildings have previously collapsed, and cost a lot of lives / money etc.
Engineers are also generally encultured into a professional culture that emphasizes disciplined engineering practices and technical excellence. On the other hand, modern software development culture actively discourages these traits. For example, taking the time to do design is labeled as "waterfall", YAGNI sentiment, opposition to algorithms interviews, opposition to "complicated" functional programming techniques, etc.
A huge number of roles casually use the "engineer" moniker and a lot of people who actually have engineering degrees of some sort, even advanced degrees from top schools, are not licensed and don't necessarily follow rigid processes (e.g. structural analyses) on a day to day basis.
As someone who does have engineering degrees outside of software, I have zero problem with the software engineer term--at least for anyone who does have some education in basic principles and practices.
Of which the Sydney Opera House is one of the better known examples.
Original developer is long gone. Me and another guy are two of the only people (we aren't a tech company) who can re-learn Perl, upgrade multiple versions of Linux/Apache/MySQL, make everything else work like Kerberos etc...
Or maybe I'm one of the only people dumb enough to take it on.
Either way, nobody will get so much as an attaboy at the next department meeting. But, they'll know who to go to the next time some other project is resurrected from the depths of hell and needs to be brought up to date.
If anything, big companies are better about tech-debt squashing, and it's the little tiny companies and startups that are, on average, spending less time on it.
I will preemptively agree that this isn’t possible everywhere; but if you create a good work environment where people don’t feel like puppets executing the PM’s vision, they might actually care and want to do a solid day’s work (which we’re wired for).
Eventually things get so bad that there's no choice but to abandon feature work to fix them.
The business loses out multiple times. Feature work slows down as developers are forced to waste time finding workarounds for debt and bugs. The improvements/fixes take more time than they would have due to layers of crap being piled on top, and the event that forces a clean up generally has financial or reputational consequence.
Collaborative decision making is the only way around this. Most engineers understand that improvements must be balanced with feature work.
I find it very strange that the industry operates in the way it does. Where the people with the most knowledge of the requirements and repercussions are so often stripped of any decision making power.
I won't say procrastination is a virtue. But sometimes the deferred task really does cease to matter.
Valve?
Consultancies are by far the worst, a project is done and everyone moves on, yet the clients still expect quick fixes and the occasional added feature but there's no one familiar with the code base.
Developers don't help either, a lot move from green field to green field like locusts and never learn the lessons of maintaining something, so they make the same mistakes over and over again.
It’s very rare, this is one of the only places I can imagine something like that happening.
Edit: seems I misunderstood, ignore me
So old products are thrown away while new products with similar functionalities are being created.
Both teams are happy. The users suffer.
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.
Or shitty software dev companies that push out crap to meet marketing deadlines.
Either way, take your money elsewhere.
It's not like there's just some "go_slow=true" constant that just needs changing.
This write-up really points the finger at not solving occlusion culling or having good LOD discipline.
Give a person a dedicated optimization mandate and you can avoid most of this. One of the first things I do when I'm profiling is to sort assets by tris count and scan for excess. I wonder if they had somebody go through and strategically disable shadowcasting on things like those teeth? I am guessing that they made optimization "everybody's responsibility" but nobody had it as their only responsibility.
There are tools for creating automatic LODs that come with their own pro's and con's. A bad LOD chain can express itself as really obvious pop-in while you're playing the game. There's also these things called imposters that are basically flipbook images of an object from multiple angles that can be used in place of the true 3d geometry at a distance. Those are created automatically. They tend to be like 4 triangles but can eat more vram because of the flipbook sizes.
Unreal engine has nanite, which is a really fancy way to side step needing LOD chains with something akin to tessellation, as I understand it. Tech like that is likely the future, but it is not accurate to describe it as the "way most games are made today"
However, I also find the suggestion that because there are other high profile examples of unity projects with performance issues, it must be a problem with unity.
You don’t hear that about Unreal Engine, despite the fact that there are poorly optimized UE games.
Such a bizarre set of assumptions.
It definiitely has much to do with how UE's PR constantly shows off and ships new and exciting features that blend in the engine. Meanwhile, Unity has been criticized for some 6+ years minimum for its package management and lack of cohesion.
The fuck up here is whoever was handling the art assets. You simply do not ship a game with such detailed graphics and no LODs. They must've simply been downloading things off the asset store and throwing them in without any regard for performance.
Just the other night I wanted to know what it'd take to do some AR development for the Quest 3 using Unity. 10 minutes in I was straight up confused. There's AR Foundation, AR Core, AR Kit, and I think at least one other thing. I have no idea the difference between those, if they're even wholly separate. That's on top of using either the OpenXR or Unity plugin for the actual headset.
Open XR is also an an attempt to make a cross platform layer for vendor specific APIs. Again not Unity's fault. The Unity plugin system is a common interface for all XR devices.
I'd generally support your sentiment but in this case you're picking on things where Unity had mostly got it right.
I know what Open XR is all about but again, it's not clear which you should actually use for development if you're only targeting Quest devices, for instance. A little extra documentation would go a long way.
The same goes for all of the other things so frequently mentioned like their renderers.
what does this mean?
my condolances. the Build iterations and ancient CI workflow was by far the biggest complaint for the teams I was on and talked to. it takes so long getting stuff properly landed into trunk that I can't really blame the teams wanting to break off if possible (it fortunately was for my division).
But I'm guessing it was hard to convince product or execs that dev velocity matters, so we were all just wading in muck. I heard things were improving... but I heard that every month I was there.
>executive leadership wanting to run the company like Adobe
I think I know what you mean by this, but can you clarify?
Godot has this: https://docs.godotengine.org/en/stable/tutorials/3d/mesh_lod...
Unreal has this (for static meshes): https://docs.unrealengine.com/5.3/en-US/static-mesh-automati...
Aside from that, agreed: the multiple render pipelines, the multiple UI solutions, the multiple types of programming (ECS vs GameObject) all feel very confusing, especially since the differences between them are pretty major.
They played around with the idea of automatic LOD, but the repo they had hasn't gotten updated in a while: https://github.com/Unity-Technologies/AutoLOD
The closest to that would be looking at assets on the Asset Store, for example: https://assetstore.unity.com/packages/tools/utilities/poly-f...
An exception to that is something like the terrain, which generates the model on the fly and decreases detail for further away chunks as necessary, but that's pretty much the same with the other engines (except for Godot, which doesn't have a terrain solution built in, but the terrain plugins do have that functionality). I guess in Unity's case you can still get that functionality with bought assets, which won't be an issue for most studios (provided that the assets get updated and aren't a liability in that way), but might be for someone who just wants that functionality for free.
[1] https://en.wikipedia.org/wiki/Level_of_detail_(computer_grap...