Collaborative document/code reviews
I have come across situations time and again where an author creates a document in half-cooked stage and floats it for review for initial comments.
This is typically followed up with a meeting, which is mostly inconclusive, as people debate on something that does not exist or some of them take extreme viewpoints. Except for that half-cooked document there is nothing on the ground level. This is further followed with minutes of meeting, document update by author. After updates, optionally reviewed with moderator, it is again floated for review. Many times at this, document is complete in its contents. However, it may have lots of errors or gaps. Again reviewers have a look at it. Lots of comments pour in. Meeting that follows this is typically of a marathon nature.
Limited by bandwidth of all participants, this never 100% done. After this second review, author capture minutes, updates the document based on conclusions from meeting and his own understanding and floats it for final check. Many of the reviewers at this third stage are already in don’t care state. And typically document gets through approval as one of the versions and subject to further evolution under change management.
Above is typical of the organizations where culture is dominated by 15-20 years of experience guys. This is the generation which has started from 1990s and is used to bureaucratic setup. They are also in their 40s where typically people resist to change.
Today people spend more time on social networks than before. They are more comfortable being offline rather than meeting up. People don’t believe in delegation but doing things on their own and sharing with the world. Time is expensive, unpredictable and so many things to do. Hope it does not reach to the state where you ignore home front. Thankfully, things get complex only when there are alternatives to take care of that complexity. Having said, we must re-look at how deliverables can evolve and probably many organizations already pursue better than the model I am trying to present here.
Let’s talk about a module being written by a group of developers (e.g. 4 in number). They are working on different files and are supposed to review. How they should go about? Also, assume their organization does not spend on real-state and hardware to work on software. So they work out of their homes from distant geographies. In such scenarios, they will establish some basic collaboration discipline, have few calls. Agree on things like – when they will commit the code into repository, naming convention, the area where they will operate/make changes, communication medium, availability period and exchange on their status of work completed and share thoughts / ideas related to implementation. Now, all this they keep a record on their network either through bug management tool, Google docs or discussion forums. Even dumb tools like emails, files and flat directories can be used for this purpose, though may not be as efficient. It is like doors of limousine open for you to travel, but you insist to take auto.
Let’s say developer A finished working on module A – feature x, he notifies others about it. All will start looking at it and make changes to it as they feel like is a better alternative. This is now their version of Developer A – Module A – feature x. Now it is left to the developer to evaluate and take in these changes. Clearly, the reviews this way is not in the air. The person who says I am competent to do review and can add value, is actually adding value by making those changes.
Also, note that in this scenario, the reviewers may use the updated information to integrate with their piece of implementation to justify the changes needed.
Now, in case the change is not acceptable by author, it can be discussed directly between the two in the forum, over the phone and recorded minutes seen by all. As it stands rejected, the content is always logged in reference to Module A and can later be picked or referenced by author/reviewers in some other context. This was never a possibility when meetings used to happen over some suggestions which are few lines of text.
In nutshell, some time spent on putting relevant tools to support this type of collaboration can help cut down waste time in meetings and increase productivity and quality manifold. As IT industry has come of 20 years of evolution, it is important for old organizations and people to look at things in reference to evolving tools and with it the evolving tool savvy smart generations.
