Continuous Inspection: Sharing A Practice

There are several ways to achieve continuous inspection. Some organisations do it by pair reviewing where one person types and the other is considered suggesting code and design improvements. Some teams have another developer review their code before committing it to the VCS repository. Some follow formal peer reviews, in which a developer's peers watch the code and offer better ideas. And may be few more.

In our case we do it using code reviews, which is more like the second form, I have mentioned in the paragraph above. But we do it after committing to VCS. Not a good thing right? I would elaborate it later. The other way we follow is pair programming which is not exactly the form of continuous inspection, but it helps in some way, if not exactly.


Pair Programming
It something annoyed few of our team mates, including me, in the beginning. Nobody was comfortable when someone is watching while the one programs. But after practicing it for a few weeks things changed. One important thing is we must switch in both ways for example, I watch, you code now you watch, I code; and the other is switching the partners so everybody knows everyones weak and strong points and the style of coding. That brings a drastic personal improvement. We found it as an efficient way for some tasks and bad, not really bad but inappropriate, for others. This works best when its about to train a new developer, to implement something complex or not routine and it helps transferring the skills as well. So, now we don't practice this for every other task.

After getting all these benefits, one benefits which it gives you the code quality and most of the time you don't really need to inspect the code exclusively.

Code Reviews
This is the thing, we merely follow for continuous inspection. In our team we found that most of us are very good in coding but not as good in reviewing other developers code. So, what we did was, we generated code review tickets using hook script provided by our project management system. Its your choice how you want to generate it whether you want the tickets to be assigned randomly or in a particular order. Now, on every commit we have a code review ticket assigned to any of the team mate. He/She needs to review it and then close it after making appropriate changes, if required. This way we got a good improvement in the skill of understanding other developers code and the design pattern we should follow for a particular scenario. We improved on software quality, bug reports, code clarity.

Please share your's in comments. Thanks.

Related Links:
Automation for the people: Continuous Inspection
Paul Duvall on continuous inspection with software inspectors
Peer Reviews in Software: A Practical Guide