Read a blog by a game developer (apparently) recently that was fairly down on code reviews. Here's a quote:

Our finding? Although we did find some "bugs" early, most of them were not stop shipment bugs. Readability bugs, guideline violations, sure. Every now and then, maybe every other review, we found an actual stop shipment bug and were like, Yes! Good catch!

But we estimated that the amount of time we would have spent fixing the stop-shipment bugs later was actually less than the amount of time we spent reviewing code.

Hrm. That's kinda sad. Where I'm working now, we're pretty big on one-offs, much moreso than I would like. We are, however, the Custom Software Development Team, and the whole advantage of custom programming is that you can make something awfully quickly percisely because your audience is so small and you can cut a lot of corners you wouldn't if you were programming for the generic masses.

That said, programming for the now is still a very short-sighted proposition. If you plan to reuse code in the future (and there's been hardly a project I've worked on where I haven't), you're every bit as worried about "readability bugs" as "stop-shipment bugs".

I know I'm an idealist and my tack could probably use some realism, but if you're only programming for your next release, you'll find yourself starting over from scratch next time. And that's got "delayed [next] shipment", every bit as bad in the long run as a stop-shipment now, written all over it.

And while I'm at it, run over to thinksecret.com and check out the new G5 specs!