> Maybe these supposed anti-patterns don't really matter as much as we think they do for successful software? Given that plenty of successful software has them.
There's more than one variable involved. You can write successful software full of anti-patterns, but you'll probably pay for it in some other way (like increased QA effort or a low bus-factor [1]).
The motivations around those kinds of factors are different for games, though.
e.g., bus factor has to be weighted a lot more highly on software that needs to be maintained indefinitely than it does on software that is going to be shipped on a fast-approaching deadline and then (probably) never touched again.
Also, bus factor's importance depends on the size of the team. In the limit case - a 1-developer project like VVVVVV - it's meaningless.
It’s not meaningless when you’re spending exponentially more time debugging random bugs due to lack of architecture (which usually implies you can’t properly test anything, too).
Doesn't 'success' encompass all these variables at the same time?
If you can be successful with a very high QA effort then fine. If QA costs were too high then you wouldn't be making money and you wouldn't be successful.
If you can stay successful with a very low bus-factor then good for you.
This is a game that has gone through a few revisions by different authors. And whilst I doubt any of them were happy with the hand they were dealt it still shipped after their work. So maybe it had increased QA effort over the baseline version that doesn’t exist but it certainly had no bus factor.
There's more than one variable involved. You can write successful software full of anti-patterns, but you'll probably pay for it in some other way (like increased QA effort or a low bus-factor [1]).
[1] https://en.wikipedia.org/wiki/Bus_factor