Games have two other elements that make them an oddball:
1. The data integrity mostly doesn't matter. Crashes, corruption, whatever. Just throw playtesting at it until it kind of works. Higher discipline than that is only needed for multiplayer.
2. Most of the engineering exists to support a pipeline to create, load and render specific assets at a specific level of dynamism, ranging from "menu text" to "skeletal animation" to "character creation". It's the definition of what an asset is or can be, and how dynamic it has to be, that can make the difference between "days" and "years" of development. A team that can argue its technical case eloquently can chop out the most expensive kinds of assets, make extremely shoddy tools to help deliver the ones that remain, and still end up with an engaging experience.
When we discuss old engines like Quake, the genius in them is primarily in finding exactly the right specification of assets to hit the target machine of the time while achieving previously unprecedented levels of detail. It's easy to make a game on modern hardware run at 500hz if you stick to rendering Atari 2600-grade scenes - it's the additional detail that turns it into a major project to hit 30hz.
Today the burden in games has shifted away from the runtime performance costs of a scene - since there are a lot of standard methods of getting an acceptable result, including entire engines with level-of-detail systems to help automatically downgrade graphics - and towards the production cost of achieving detailed assets, which is more in the realm of what technical artists now do as a dayjob.