Well... It's a many-body problem. It can't be solved analytically. In molecular physics (since they are all multi-body systems) you often make a bunch of assumpions about the motion of the nuclei not effecting the electrons, which is pretty close to true at normal energies, visible light, for instance. Pumping the energy up into this range gets to the point where you can't ignore the nuclear motion, so you get into areas where the usual equations don't work. Having real measurements of what is going on helps the theorist see which of the things he has been ignoring are important, and which aren't.
I have been at companies that did code reviews of everything, and it is usually a god thing if they are run well (egoless, and without management being present). On large projects (OS) we had a policy that nothing went into the build without a review. They are especailly necessary with code you inherit but didn't originate. But most people I work with can code reasonably well,and you don't want to spend a lot of time with coding standard discussions.
The critical thing in most projects is to do DESIGN REVIEWS. Much more important than code reviews. Even experienced people often miss some unspoken requirements, or build in unecessary restrictions. And the people who do a design review will have a much better understanding of what the component they are reviewing does-does well-does sorta-doesn't do, and will then be able to use it in a more appropriate manner. It is very expense (often impractical) to fix design errors.
Slashdot Mirror
Well... It's a many-body problem. It can't be solved analytically. In molecular physics (since they are all multi-body systems) you often make a bunch of assumpions about the motion of the nuclei not effecting the electrons,
which is pretty close to true at normal energies,
visible light, for instance. Pumping the energy up into this range gets to the point where you can't ignore the nuclear motion, so you get into areas where the usual equations don't work. Having real measurements of what is going on helps the theorist see which of the things he has been ignoring are important, and which aren't.
I have been at companies that did code reviews of everything, and it is usually a god thing if they are run well (egoless, and without management being present). On large projects (OS) we had a policy that nothing went into the build without a review. They are especailly necessary with code you inherit but didn't originate. But most people I work with can code reasonably well,and you don't want to spend a lot of time with coding standard discussions. The critical thing in most projects is to do DESIGN REVIEWS. Much more important than code reviews. Even experienced people often miss some unspoken requirements, or build in unecessary restrictions. And the people who do a design review will have a much better understanding of what the component they are reviewing does-does well-does sorta-doesn't do, and will then be able to use it in a more appropriate manner. It is very expense (often impractical) to fix design errors.