The game industry has a completely different way of working compared to other tech fields. Most of their practices seem old fashioned, or anti-patterns, etc. if you look at them from an outside point of view.
But they're trying to do something very hard: control both quality and deadline. It's not like an open source or enterprise IT project. The game has to be finished, good, by a given date. To do that they do many things, including slaughtering sacred cows about how things are supposed to be done. If hard locking saves them time by avoiding wasted efforts, by artists who are probably over-worked already, then what's the problem?
> But they're trying to do something very hard: control both quality and deadline.
Do you believe other tech fields are not trying to do the same exact thing? Do you believe that enterprise IT projects are somehow less beholden to both quality and deadlines than video games?
Controlling both quality and deadlines is what literally every (professional) software development project should be doing. The implication that game developers are somehow better about or more cognizant of this (let alone specifically because of broken development workflows) is pretty rich considering how frequently big-budget video games end up in development hell (see also: Duke Nukem Forever) and/or end up riddled with bugs (see also: literally everything Bethesda's released in the last decade or so).
(Not saying that enterprise IT is necessarily better in either regard, of course; bugs and delays are inevitable as software complexity grows, be it an RPG or an ERP...)
> If hard locking saves them time
It doesn't save time in aggregate, though. It maybe saves time for one specific corner case (conflicting edits on binary files) at the expense of slowing down everything else.
And if you're at the point where "conflicting edits on binary files" is no longer a corner case, then that betrays at least one of two dysfunctions:
- You're using some sort of container format instead of sanely keeping things split into separate texture/model/animation/normal/behavior/etc. files (and then - if the amalgamated container file is indeed necessary - combining it as part of the build process). If you're really running into a lot of cases where multiple people are trying to edit the exact same normal map at the exact same time, then...
- You've got a communications breakdown somewhere. You can band-aid over that with file locking, but that still doesn't address the issue of two people trying to independently edit something in the first place.
But they're trying to do something very hard: control both quality and deadline. It's not like an open source or enterprise IT project. The game has to be finished, good, by a given date. To do that they do many things, including slaughtering sacred cows about how things are supposed to be done. If hard locking saves them time by avoiding wasted efforts, by artists who are probably over-worked already, then what's the problem?