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 are forced (through influence) to play by them.
One of the rules of developing quality code is to make sure code is being reviewed. This has many benefits that might be overlooked at first glance. In my experience, developers are proud individuals, certainly of their code. If they know someone else is going to review it and judge it, in most cases they will put in just a bit of extra effort. 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. To be fair, there are some disadvantages, too. Time. This 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 is trying to get the software built as fast as possible with as much quality as can be delievered. These two objectives can seem to be in conflict depending on how you look at it.
I have been in many software organizations and have seen code reviews done many different ways. Some I liked and some no one liked. Based on my experience, I have a way to implement code reviews that has worked for me in the past and I feel is timely and effective at the same time. Email, Code Review repository, and the Enforcer.
Start with a Coding Standards document. This is obviously the yardstick against which all code will be measured. There are great examples on the internet regardless of the development language. Next step is to make sure your lead developers agree to the standards and believe they are important, as they will be the ones initially mentoring the other developers. Thirdly, start by handing out small coding assignments. With more departments moving to an Agile methodology this is becoming easier. The next critical step is that the developer understands that, for the assignment to be complete, they must have a peer fill out the Code Review form and upload it to the repository. Make sure this peer is different for each assignment so they don’t get into cahoots. By making it a responsibility of the developer, it assigns ownership of their work. Finally, let it be known that these forms and the code will be reviewed at random by the “BIG BOSS.” 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. This is an opportunity for other developers to learn and to put just enough pressure to keep lazy developers from being lazy. The Big Boss is anyone with a technical background whom the developers respect. The Big Boss can be anyone: the Senior Lead Developer, Software Architect, or the Development Manager (that’s my favorite). Just make it someone who can review a form, some code, and provide feedback. With this in place, all you have to 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 short-cuts. Follow up and make sure the reviews and corrections are happening by having the Big Boss speak publicly (and positively) about someone’s code. This will provide evidence to the developers that someone is reviewing these and their ownership is being associated with it, be it the developer or the reviewer.
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 desk.