Mi equipo ha hecho programación en pares desde su inicio, mucho antes de que trabajara allí, como parte de una tienda de estilo de "programación extrema". La programación de pares es el estado predeterminado ; las personas solo se vuelven locas si hay un número impar, u ocasionalmente para investigaciones, especialmente aquellas que involucran jugar con equipos hostiles e intentar que funcionen.
"Junior / senior" no es el único camino a seguir. "Intermedio / junior" es útil; ayuda al individuo de nivel intermedio a sintetizar el conocimiento que ha obtenido al obligarlo a comunicárselo a otra persona. Los desafíos "Intermedio / Intermedio" dos personas trabajan juntas para compartir sus conocimientos, comunicarse y trabajar como parte de un equipo. E incluso si tiene dos jugadores realmente mayores, es probable que tengan diferentes áreas de experiencia y puedan llegar a diferentes enfoques. Los aspectos de intercambio de conocimientos no terminan una vez que alguien está vagamente "al día" en un proyecto. Más bien, la programación de pares es el epítome de una organización de aprendizaje . Nuevas técnicas y mejores prácticas se difunden rápidamente.
La programación en pares también ayuda a mantener la calidad del código (menos defectos) y la cordura del código (no solo hace lo que pretende, sino que hace lo que debería ... idealmente, sin pasar por un agujero de conejo de varias semanas haciendo lo incorrecto, o dos cosas correctas diferentes que tendrán un conflicto salvaje). Ayuda a los programadores a mantener su enfoque: aquí, en el corazón de Silicon Valley, hogar de la semana laboral de 80 horas, podemos trabajar solo 40 horas a la semana porque estamos haciendo una codificación intensa durante ocho horas al día, cambiando las cosas fuera el uno con el otro. (Además, si fuera más tiempo haciendo la programación en pares, probablemente se desvanecería. O al menos se agotaría). Esto es excelente para el equilibrio entre trabajo y vida, y también ayuda a su organización cuando es importante tener un cambio rápido (en particular, un cambio de baja latencia).
No es todo, completamente, 100% duraznos y crema; Encuentro que la programación de pares es ocasionalmente un obstáculo para mi aplicación de procesos cerebrales intuitivos que son útiles en ciertos problemas. Más recientemente, en una tarea de pérdida de memoria, pasé un tiempo con y sin pares; sin uno, me sentí más libre de perder el tiempo y probar experimentos sin saber realmente exactamente cómo explicar lo que estaba haciendo en un momento dado. También hay algunas ventajas en el trabajo de singleton, ser capaz de irse en una tangente y hacer ciertas refactorizaciones salvajes (valoradas en la metodología de XP) en un capricho.
Pero en general, los beneficios superan con creces los costos, y el emparejamiento ha funcionado espectacularmente bien para nosotros: desde la etapa inicial hasta la adquisición por parte de una empresa más grande, y nuestra posterior integración. (Hablando de eso, la programación en pares nos ha ayudado a mantener una continuidad de la cultura a través de la expansión y, a pesar de un poco de rotación).
(Desarrollamos un dispositivo de software en Perl, ~ $ 4,000- $ 40,000 precio de lista.)