As a eXtreme Programming follower, I like reviews, especially the peer-to-peer reviews. In fact, as a software engineer I think reviews are necessary. Reviews help in bringing attention to faults before they go into the testing when the effort can get magnified. I have experienced that reviews are effective and help in building better software by contributing to its quality.
Having said that, there is still a problem with reviews that keeps nagging me. A lot of times, ends up in the do-undo-redo cycle. Sometimes this cycle becomes recursive, harming the project more than expected. I believe that this is one of the primary reasons a project shoots its expected time. It is acceptable as long as it is only about code change. It becomes more expensive it gets into design change with the worst case being the developer having to unlearn something.
And I always keep wondering what is the best way of eliminating or at least minimizing this effect. If the undo has to be avoided, it has to be correct the first time. And this implies that it is not only about the individual, but about the team work. Every developer has to get his/her pieces right before it goes out to someone else. For this to happen
- Every developer has to know exactly what to expect from and whom to give what, which I keep calling interface.
- Every developer should know the level of skill expected in the project.
- This I believe is the strongest – every developer has to have complete trust in rest of the team. There is nothing better for optimum collaboration.
However, it is impractical to expect this from every individual. But we can expect to minimize the undos and redos if they are trained to do so. Trained not only to give their best, but trained to trust and trained to collaborate. What does this mean? This means that before a developer starts working on the his/her piece he/she has to understand the big picture and how the pieces fit together. Only then can the developer take informed decisions the first time that reduce the amount of undos/redos. This is usually omitted in most of the trainings conducted by the corporates.
Of course it is always a fact that things change. Requirements change, designs change, codes change, but this change can be effect quickly if every developer knows what to change where. And this can happen if he/she has complete understanding of the big picture. This, I believe, is easier in a smaller team but starts getting difficult as size of the team starts increasing. The process should make sure that every team member is imparted knowledge about the technical and business aspects of the project.
As I am writing this I saw JP’s thoughts on similar lines about quality first where he gives an excellent example about field gun exercises.
To continue, reviews are necessary, but we need to make sure that the number of undos/redos minimize. That is the only way to improve quality and delivery of the project.