Editorial Note: I originally wrote this post for the SmartBear blog. You can check out the original here, at their site. Check out my posts and some of the others and take a look at their products as well while you’re there.
If you work for a smallish company, as part of a modestly sized software development group, the path to a code review policy is likely a short, direct one. It could be as simple as a respected team member or the manager saying, “hey, let’s start doing code review.” But whatever the impetus, the participants will tie the process closely enough to the desired outcomes from it to adapt it as needed.
The Capital E Enterprise
At the enterprise level, the calculus changes considerably. And when I say the enterprise, I mean The Enterprise – a size and scope mammoth enough to demand capitalization, even when the rules of grammar do not. These are companies so big that those who work at and have worked at them will assure you that there is simply nothing out there that’s comparable. There are, they will tell you, an entirely different set of rules that apply. And they’re more or less right.
The Enterprise loves structure and hierarchy, usually of the command and control variety. The scale is so immense that the only structure up to the task is a pyramid reminiscent of a military chain of command. The organization lumbers along like a battleship, powerful, majestic, and requiring incredible teamwork, cooperation, and precision to change direction in any way.
In this environment, code review tends to make its way to development team in a very different way and for very different reasons. Of course, even in a massively homogenized environment, one size does not fit all for the development teams. But the cog in a larger machine dynamic makes the following sort of scenario much more likely.