Whether they know it or not, most game industry folks are intimately familiar with the old 80-20 rule.  That is, it takes 20% of the time to get 80% of the work done, and 80% of the time to complete the final 20%.  This raises an important question for all developers:

How much is enough?

This is one of those questions that doesn't have an answer, but it can still be a useful thing to think about.  I will try and explore some options and examples that show what sorts of compromises you can make, and what the effects might be.

Prototyping and Pre-production

I'm putting this first because it's kind of a special case, or at least the rule seems to apply differently here.  Prototyping is all the upside of the 80-20 rule; you are building little playable tech demos with no polish, so you never really get into the bad part of 80-20.  Getting this part wrong can have disastrous effects on the 80-20 relationship later on...maybe more of a 100-0 ratio or something.  There is a reason that master oil painters still do charcoal sketches before they dig in!  Classic examples of heavily prototyped designs include Super Mario 64 and Resident Evil 4.  Messing around and making the most of this stage can yield unexpectedly pleasant results as well, like when Mikami's early builds of RE4 launched the Devil May Cry franchise.  Of course, if you are going to spend 5 years developing a game, you need a bit of a warchest and maybe some co-development, or your boat is going to start filling up with water pretty quick!

VERDICT: It's hard to prototype too much, as long as you can afford it.

Programming Production

The 80-20 rule manifests itself in ugly, frustrating, no-more-weekend kinds of ways in the realm of coding.  Getting the basic systems put together is usually a relatively straightforward process, but tracking bugs, accomodating new platforms, feature creep, and optimization all have the ability to hit back really hard.  Not to mention distributor lot checks and QA!  Unfortunately, this is one place where it's very difficult to just say "F*ck it, that'll do."  Your game might not ship at all, it might get critically panned, or it might not work on anything ever.  There are a lot of things you can do to minimize some of these issues (I'm sure every coder that reads this will automatically think of making modular code, working on organization and API design, etc etc).

There's another way to help put a dent in this stuff though, that is a bit of a turnoff for a lot of coders and designers, which is to just work on ideas that do not require insanely highly optimized code in order to work properly.  This makes porting easier, opens up the number of platforms you can build to, and should help minimize some of the brutal 80-20 backend on your coders too.  This isn't an option for all designs or all studios, but there is a lot to be said for a tight design that doesn't require Black Magic Code Voodoo in order to operate properly.

VERDICT: Always go 100%, but the easier that 100% is to hit, the better.

Art Production

This is a really hard area, made even more complicated by outsourcing and parralax occlusion mapping and 1080p HDMI TNA, not to mention our unhealthy obsession with cinematic duplication.  I would argue that at least currently, from a purely financial standpoint, a vast majority of the graphical detail crammed into most AAA titles is unnecessary.  I'm not saying that that's a good thing or a bad thing.  This is just a financial thing; the wii, PS2, and DS are happily and persistently outselling the 360 and PS3.  I'm not talking about historically either.  More PS2s sell in any given month than PS3s.  One message you might take away from that is that for most people, all that glamour is not actually their top priority.

Obviously, I don't think anybody could get away with claiming that Little Big Planet or Gears of War would even be the same game if they'd phoned in the artwork.  On the other other hand, some of the most beautiful games of the last year are very minimalist or rely on older, cheaper art production methods like pixel art.  Advances in procedural content can also help modulate some of the expense of going for extremely detailed presentation.  Think about having blurred or dark backgrounds as a way of implying detail, rather than having to explicitly model things even when it won't be right up in the player's face. Think about fixed camera angles that can help reduce the amount of detail required in the environments and entities.

Even Disney's recent CG outing Bolt has some nice hand-painted frames, where CG modeling just didn't make the most sense financially.  Choosing a style that is less work but relies on the unique creative strengths of your art team is a pretty safe way of both getting attention and creating something with a reasonable budget.  Dylan and the Q-Games team are doing very cool work with relatively cheap and simple visualization.

VERDICT: Think really hard about what kind of 80-20 curve you want to bring down on your art team, and then pick your battles.  Also, creative collaboration between art and code teams can yield huge benefits.

Design Production

This might not be the right term, but I'm lumping stuff like level design, scripting, and all that good stuff under this banner. These are tasks that consume immense amounts of time in both single player and multiplayer games, though single player seems to take the brunt of it.  As opposed to prototyping, which rests mostly on the happy side of the 80-20 line, many of these tasks reside solely on the dark side.  We know what the game is going to look like, we know how it is going to work, we just have to figure out how to make 20 hours worth of levels and bosses.  And cutscenes.

In Derek Yu's RL-inspired Spelunky, every level is procedurally generated every time you play.  In my game FATHOM, level geometry is created on the fly each time as well, as is tile placement.  This approach alleviates pain-staking hand-placement and design, inherently creates some nice replay value, and also ventures into territory that is pretty unique to games.  And even very simple level layout algorithms are able to produce surprisingly playable, organic environments.

However, I think that throwing away everything the player knows about the game's geography has the potential to be extremely intimidating to more casual players; Spelunky is seriously difficult.  This may be due to the game's hardcore roots, and not necessarily to the changing geography, but this is a pretty new area for more modern games that is going to become more and more important.

VERDICT: Hurry up, technology!  This stuff is all on the bad side of the 80-20, and we need to start chipping away at it ASAP.

Again, these kinds of questions don't really have answers, and depending on your team, your platform, your publisher, and your design, these are very slippery sliding scales.  There are no set in stone rules or magic solutions to these problems, but there are long term ideas that we can all keep in mind in order to avoid wedging ourselves even farther under the 80-20 rule.