> No comparison is entirely fair but I think your objection is unfounded.

I should have clarified.

Doing an absolute numerical comparison in terms if "bad game code" to "bad B2C code" is unfair, because now days there is a lot more game dev code than B2C code (if we ignore the web, which is a rather lot of code to ignore I'll admit :) ).

All that said, most of the games on my phone run very well. Most of the games on my PC run very well. Do the massive over budget AAA titles have issues? Of course. Human organizations are really bad at creating large projects, we all know that social interaction overhead scales non-linearly with # of people, large projects get bogged down.

(Now throw in B2B software where the CTO makes the purchasing decisions and only people lower level in the company have to use it. All of a sudden enterprise software starts to suck as much as AAA games!)

> The philosophy is that you can just go ahead with bad code because you can always fix it with a patch later on.

Sure, for AAA games. But plenty of games that I play don't have those sorts of issues.

Meanwhile my Windows start menu only opens every other time I press the start menu button. This happened for years, then it was fixed for a bit, then a few patches later it started happening again.

The start menu on Windows should be the 2nd to last thing that breaks, right behind the mouse driver.

Without huge testing efforts, large software projects will collapse under its own weight. The type of software isn't material to the problem.

> One other problem is that eventually some people coming from the gaming industry will end up switching to other types of software development but will stick to the philosophy.

I've hired plenty of ex-game devs, I agree they have some holes in their skills. But I've also found out that if you sit them down they can write code that traditional software engineers couldn't manage. Spending too long in any one paradigm fixes ones mindset into that paradigm.

I also agree that the quality of code someone puts out is highly influenced by the environment they work in. But I've worked with plenty of ex game devs who take pride in writing correct code the first time around.

> Whenever someone came with most of their career in game development or most of the recent experience I asked for the CV to be put at the bottom of the stack.

That's a shame, because I wouldn't have accomplished some of the things I've done in my career if I hadn't hired a few game developers along the way! I've seen some stupid crazy stuff get pulled off, code that "shouldn't be able to exist", but did exist, and was rock solid reliable, all written by game developers.

People are people, and sure 9 out of 10 the person who bangs on kernels for a living is probably super careful about every line of code they write, but I'm not going to judge an entire field because the most bureaucratic outputs of that field are horrible.

That'd be like saying everyone who writes web apps is an incompetent developer because Jira is slow.

Or that all software developers are bad because, honestly, the majority of users only notice what we make when it breaks.

Well, we only hear about the small % of games that have huge problems, not the larger number of games that work just fine out of the box.