The synchronous aspect is a problem, although not a huge one. The issue is mitigated to a certain extent by excluding non-customer facing research & testing components from the review requirement. Also, the architecture of the system is such that people tend to work very independently, with little-to-no overlap, so reviews can be postponed with little impact on velocity. As our team grows in size, we could also think about instituting a rotating code reviewer responsibility, with team members taking it in turns to act as the designated reviewer for the day.
Comments
This is an interesting practice, thanks for sharing. I'm really curious about different sorts of hybrid approaches being used in the wild.
I'd be curious to hear how the day-to-day schedule ends up working out between developers, since the review process is synchronous in this case.
The synchronous aspect is a problem, although not a huge one. The issue is mitigated to a certain extent by excluding non-customer facing research & testing components from the review requirement. Also, the architecture of the system is such that people tend to work very independently, with little-to-no overlap, so reviews can be postponed with little impact on velocity. As our team grows in size, we could also think about instituting a rotating code reviewer responsibility, with team members taking it in turns to act as the designated reviewer for the day.