Ever wonder how companies get quality software out on time? Structure. That’s how. There is a development manager that has provided “Structure” to his department. Whether the developers like it or not, they know the rules of the game and have to play by them.
One of the rules of developing quality code is to make sure code gets reviewed regularly. Regular code reviews have many benefits that can get overlooked at first glance. In my experience, good developers are of their code. If they know someone else will review it and judge it, they will put in just a bit of extra effort to make sure it is clean. It will keep them from cutting corners under the pressure of an approaching deadline. Also, it gives other developers a chance to learn by reading someone else’s code. There are some disadvantages, too – mainly time. Time is the critical piece to any software project. As soon as someone says, “I need some application to do this thing,” the clock starts ticking. From that point on, the customer wants their software built as fast as possible without sacrificing quality. These two objectives can seem to compete depending on how you look at them. I have been in many software organizations and have seen code reviews done in many different ways. Some I liked more than others. Based on my experience, I have a way to implement code reviews that is timely and effective at the same time: Email, Code Review Repository, and the Enforcer.
Start with a Coding Standards document which is the yardstick against which all code gets measured. There are great examples of these on the internet regardless of the development language. The next step is to make sure your lead developers agree to the standards and believe they are essential, as they will mentor the other developers. Third, start by handing out small coding assignments. With most departments moving to iterative development methodologies, this is becoming easier. The next critical step is that the developer understands that they must have a peer fill out the Code Review form and upload it to the repository for the assignment to be complete. Make sure this peer is different for each task, so they don’t get into cahoots. By making quality the responsibility of the developer, it assigns ownership of their work. Finally, make sure the team knows that these forms and the code will be reviewed at random by the “BIG BOSS.” The Big Boss is anyone with a technical background whom the developers respect, perhaps the Senior Lead Developer, Software Architect, or the Development Manager (that’s my favorite). Just make it is someone who can review a form, some code, and provide feedback.
Remember, the purpose is to get quality code. I encourage you *not* to assign penalties to the number of comments on the Code Review form. The code review is an opportunity for other developers to learn and put just enough pressure to keep other developers from being careless. With this in place, all you must do is follow up and make sure the forms are being filled out and saved to the repository.
People under pressure tend to look for shortcuts. Follow up and make sure the reviews and corrections are happening by having the Big Boss speak publicly (and positively) about someone’s code. The public acknowledgment will prove to the developers that someone reviews their results, and their ownership is essential. Once the developers get used to having their code reviewed, it will be as normal as having their code compile, delivering successful unit tests, and eating at their desks.
