Better Than Reviews

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.

Discussion [Participate or Link]

  1. Ricky Clarkson said:

    Testing shouldn’t be a separate stage, but an ongoing process. That’s why things get magnified in the testing stage, because you assume that development has finished (for the moment). It hasn’t.

    Further, the need for reviews drops significantly if you build your system from smaller subsystems. You don’t need to read the source code for all the 3rd party tools that you use, the same applies for those developed in-house, if subsystems are well-separated. In fact, that kind of logic might even let one project be developed in multiple languages without any real problems.

    That’s not to say that reviews shouldn’t happen, but that they shouldn’t be necessary. They are very useful as a technique for learning from each other.

  2. Abhijit Nadgouda said:

    Ricky, I am completely with you about testing being integrated part of development. However, testing cannot replace reviews entirely. First, testing can only test what has been done till today, a review can check whether the code is inline with the future plan. Also, most of the times, when separate components are being developed, integrated tests cannot be run, unless something like Continuous Integration is being practiced.

Say your thought!

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.



Abhijit Nadgouda
iface Consulting
+91 9819820312
My bookmarks


This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.