Code reviews are somewhat useful for small changes. But I find that for large changes, they are TOO LATE. If someone has gone forward and made non significant changes to your software, and you happen to catch his misconceptions during the code review (dependencies he shouldn't have pulled in, improper encapsulation, volatile and frequent usage of memory, etc), he won't be able to just "address" your concerns with a few changes. He basically has to scratch most of his work. And unfortunately, few managers will see the benefit of "implementing something" better since that requires more time, and the feature as implemented "works".

Likewise, when the software design is done too long before the actual task gets to the implementation phase, the design may be out of touch by the time you get there because new constraints and problems have been discovered since the design phase.

That's why I like to have quick whiteboard sessions before someone starts implementing something. I like to know the dependencies their module will pull in, the services it will require, I want to make sure the module is kept as ignorant as possible in terms of what it knows about the rest of the system, etc. When those things are caught early on, is it almost free to correct them. But later, there is a cost. If the task is long, I like to see multiple snapshots along the way to again course correct anything before it gets too far down the road.

I work at a large video game company. I don't believe things always were the way they are now, but right now everything is tasked against "features" and it is hard for most managers to understand the necessity of infrastructure work, of unit tests, of proper module encapuslation and definition of dependencies (otherwise you find your unit tests impossible to write using your module's public interface). Every sees the short term. It is easy for them to understand that something is done when they see it in the game. But it is harder for them to understand that you want to make the process of software development more predictable, you don't want half the features in the game to be broken half the time and the shipping product to just be an instant snapshot of working features that will break as soon as the next cycle starts.

So, code reviews are useful, but they really aren't the most useful thing since they occur TOO LATE.

What is this illusion that xbox was a solid #2 behind the ps2? First, even on the xbox' strongest territory, North America, xbox was a distant second to the ps2. Second, North America was the only territory where microsoft was ahead of nintendo. In Europe xbox was more or less tied with the gamecube, and in japan we all know the xbox story.

This really speaks highly of microsoft's marketing, since a lot of people in North America (including designers it would seem) seem to be under the impression that in terms of install base, microsoft wasn't that far behind from sony.