You're right, people in the games industry can't design code, generally, but more importantly they don't. There is good reason for this. If you're writing software that gets men to the moon then:
- Get the best programmers available.
- Define a rock solid coding standard.
- Design every last operation detail of the code before writing a single line.
- Code review, code review, code review.
Unfortunately very often none of these rules apply in the games industry. The only time i've ever seen code designed to any kind of level in the industry was when a new boss of mine tried to enforce it but ended up having to drop it. There simply isn't time in the games industry because:
- You're usually working through shorter development iterations.
- Management and investors these days want to see progress on your project more frequently than they used to. (related to the above)
- Your title is out in a year and no time can be afford to be "wasted" on writing design documentation that, as soon as the game hits the shelf, is irrelevant.
I will say, however, that designing code and having good OOP has its merits. I'm not trying to say that noone in the world should be writing OOP, but in the games industry and to be honest, even more importantly for the hobbyist, don't waste all your time wondering how to add something to your perfectly architected system.
The more time you spend working out how the hell you're going to integrate physics into your engine the more time you're not spending integrating physics into your engine. You have to find a good balance between writing a codebase that will be productive to work on and also decently written and unfortunately for C++ and OOP allow you to code yourself into a corner too often.
I'm not disagreeing with you here, i understand the necessity of OOP in software engineering. I'm just not convinced the games industry is a suitable domain for it. I've been full circle with writing game engines in my personal time and my current one is my most productive. Gradually i'm migrating it over to plain C with a few C++ niceties like templates here and there.
While historically this is certainly true, I think our industry is maturing to the point where we can start to evolve out of the "cowboy coding" mentality that marked our formative years. Consider MMOs, for example -- you can't expect to build a successful MMO with poor engineering practices. You are building a service more than you are building a product you can ship and forget, a service you'll need to maintain and extend for a decade (or more, hopefully). Sure, MMOs as we know them today will eventually become passe, but some of their core elements, such as massively-connected (or "social," as the kids like to call it days) systems are probably going to embed themselves in the culture of our products for a long time. Even primarily single-player games are starting to integrate those kinds of features.
At ArenaNet, for example, we do a very good job of hitting three out of four of your bullet points. Our automated testing and test tools can be greatly improved (and we're working on it actively), but we take hiring extremely seriously, do up-front design of new systems and RFCs for changes to old ones, and have a very rigorous set of coding standards. We've developed these polices because we have to actively maintain two services -- Guild Wars 1 and now Guild Wars 2 -- for the foreseeable future and now, post-launch, we don't have the luxury of a five-year development cycle to get updates and patches out in to the live environment, so we've had to make sure these practices are followed reasonably during development so that they become habitual and we still employ them even when scrambling to patch an exploit or bug. If we don't, we're going to be building a house of cards for the next seven years -- the failure of which could basically cost the company its existence.
To your last point about writing more "C-like:" I don't think that's actually counter to the idea of writing code that espouses good (possibly OO) design principles. Such code tends to be simpler and consequently easier to read and maintain, and can still involve things like clear responsibility segregation, implementation hiding, et cetera. Much of our code at work is, for example, very C-like in its straightforwardness, and I do the same in many of my own hobby projects. Clever, complicated template metaprogramming hackery and overzealous design-pattern boilerplate implementations that adhere dogmatically to the Rules of Proper Design are, practically speaking, the domain of the academic, the "I wonder if I could..." masturbatory excursions that serve mostly to stretch the language and boost the ego of the author. Certainly, interesting innovations come from such endeavors, but increasingly I find must of them inappropriate for production code on any kind of scale.
