1. 8

  2. 2

    I’m reminded of the benefits described in the “Promiscuous Pairing” paper, where the company in question engaged in an aggressive form of pair programming intended to constantly keep people working on new parts of the code and in new pairs. In particular, they found that this approach led to really rapid diffusion of knowledge about both the local code and the broader architecture, so that pretty soon most team members could handle most tasks in most areas competently. Like a gossip protocol for your architecture, I guess.