Practical Examples in Data Oriented Design (2013) [pdf]

Extremely generalized, but here's my viewpoint:

If startups are a risky venture, video games are insane, and video game startups essentially doomed to failure.

Your window for sales is the first few months after release. After that they generally slow to a trickle. Microtransactions get brought in to rectify that situation, but then further increase the risk that players will reject your game en masse.

Spending time to make a beautiful architecture doesn't make sense. Companies that sell game engines have an incentive to do things right, but spend too long and you'll lag behind the competition in shiny features and your customers will jump ship to things that help them sell games.

Key to game development is to iterate fast and fail fast. Building up a prototype and getting it to a state where it's "fun" is crucial, and then the sunk costs fallacy kicks in and the prototype gets cleaned up and shipped.

Players are unconcerned with bugs despite often complaining about them. The success of early access games like Minecraft, Day Z, and PlayerUnknown's Battlegrounds despite often gamebreaking bugs proves this.

The disconnect between quality and success has become so pronounced that an entire subgenre of "simulators" has popped up where the core gameplay mechanic is the game being buggy and/or frustrating to play. Goat Simulator, Surgeon Simulator, Getting Over It with Bennett Foddy, and Hand Simulator come to mind here, but there are plenty more.

Hey, not the OP, but I did want to offer my 2c anyway, as someone into gamedev. I'd say you're both very right and very, very wrong at the same time.

In game development, especially with indies, in the early phases of development many developers take an approach of valuing "getting it going" over everything else. While this might sound short-sighted, it's actually a very canny decision, and often is the only way to gain enough of a foothold to ensure the long-term success of the project when you're working on a very complex piece of software like a game - see Jonathan Blow's youtube video on "The art of getting things going". Additionally there's the relationship of this approach with the game design process, where you need a very fast iteration time on prototyping game mechanics in the early stages, to start finding your way towards something interesting to flesh out into a full product.

With that being said, in commercial game development (and experienced indie developers), the performance standards are so much higher than most other fields of programming that it is actually absurd. The focus on performance of much of enterprise software, web apps, and even most native tools, is nowhere even in the same league as that of high-quality games.

I would also say that at the highest level of game development there is a very high quality level of code organization and architecture. Games are one of the most complex types of programs, involving physical simulation of a large amount of objects, skeletal animation skinning, very complex rendering and shading, realtime deterministic state synchronization over a network, audio streaming, and on, and on, and on, all happening on a realtime basis.

There's simply no room to be "ad hoc" or "hacky" in AAA gamedev because the systems involved are so complex that their architecture has to be extremely robust to even be able to finish the game at all. In my opinion, other fields of programming have a lot to learn from the lessons of game development, but unfortunately gamedev is a bit of an insular field and there's not much cross-pollination between gamedev and other industries.

Or you could just look at it like this:

AAA Gamedev: Formula 1 car

Google / AWS : State of the art metropolitan high-speed rail system

Enterprise Software: Diesel bus service

Native apps and tools: Sedans, hatchbacks, vans, sports cars

Web apps: Bicycles

Electron apps: Bicycle with a lawnmower engine welded to the frame that tops out around 20mph and gets 3 miles to the gallon

That's the meme, and I used to think that it could be true. I'd worked at some small and large game studios, and now I'm at one of the big three software companies. Things are much, much more hacked together here than in any of my previous jobs. The main difference here is that we can throw money and people at a problem: over-scale things by ridiculous amounts, hire whole teams for basic things.

At the game studios I've worked at, programmers created unique designs that worked really well for the games they were made for, usually created and maintained by a single person. These things are rarely evangelized due to lack of time, resources, or need (games still come in boxes, and the codebase doesn't need to live forever.) An outside engineer might see it and think it's poorly designed because they haven't seen the pattern on HN.

I think that we'll see more robust engineering discussion from game programmers as games as a service becomes more the norm.

This is all anecdotal, and I'd like to hear what others think.