I don't want to get into speculating budget thingies, sure $4m is a lot of money and you can get a pretty big team for quite a long time with that money, but the important fact is that they delivered the actual game and didn't shoot too far off from the schedule even. I was very positively suprised with that, and with all the problems even the launch was relatively successful in my opinion.
My only reason for wonder is why these things keep happening to them, regardless of the years of experience. And the question, or theory, I raised in the OP was:
There is something wrong with the communication between the designers and the coders in Obsidian?
Because, in my opinion, from a developer's perspective, a good designer is a coder who implements any features they design themselves.
Either that or a very disciplined process where you go through very strict iterations of design, implementation, evaluation, re-design. That's probably what the big AAA companies do, and because of that, they can manage their hundreds of staff, but it also results in less freedom between the stages, because everything needs to be documented in the between, and once design is set, you can't deviate until you get to re-evaluation (which is why it's called disciplined).
A small indie team basically doesn't need a disciplined process and they can just let creativity flow and the process is constant design-implement cycle, but this is of course problematic when you have to communicate your ideas to someone else, because there usually isn't any kind of documentation.
A bit larger teams benefit from agile methodology which basically sets very short-term goals and things are evaluated constantly, but those are generally not so good for massive teams, although you can keep creating smaller individual teams in order to have lots of agile teams.
Now, I don't know what's going on in the work culture within Obsidian, but with their track record of bad launches plus the accumulated experience they have as a studio, this leads me to suspect that something's wrong with how they do things. The old "axiom" in software development is that ~80% of IT projects fail (the number isn't really that high, but it's regardless a significant number), and the tons of research done in that show that they fail because the structure within the company, project culture, methodology, or leadership is flawed. Now I'm not saying this is the case with Obsidian, but I am raising the question I presented earlier, because if anything, I want these guys to keep making more great games, but in the meanwhile I'd also like them to get rid of these embarassing problems their games are nearly always riddled with, as well as the bad gameplay bits which are really annoying when there's a lot of awesome content, then some bull**** mechanic etc. which almost entirely ruins the experience.
Sure, bugs are everyday in any software, you can't avoid them, but there are certainly lots and lots of ways to minimize the worst ones. When really bad ones come up, it's a sign that something is usually wrong.
In fact I'd be very interested in reading through some analysis on some of Obsidian's source code, since that might actually be very revealing: There are these things called "design smells", which can be used to indicate potential problems in source code, and perform some kind of evaluation on the overall quality of the code (google "design smells SOLID" or something like that for more info). Too bad that kind of thing is generally out of the question, unless released as open source.