La programación requiere pensamiento profundo, y los pensamientos profundos requieren soledad. Así va el estereotipo del programador.
Este enfoque de “lobo solitario” de la programación está dando paso a un enfoque colaborativo, el cuál, puedo decir, mejora la calidad, productividad y satisfacción laboral de los programadores. Este enfoque tiene a los desarrolladores trabajando más cerca entre sí y también con los no desarrolladores –analistas de negocio y sistemas, profesionales de control de calidad y usuarios–.
¿Qué significa esto para los desarrolladores? Ser el experto técnico ya no es suficiente. Debes ser más efectivo trabajando con otros.
La colaboración no se trata de preguntar y responder, o sentarse en reuniones. Se trata de arremangarse con alguien más para atacar conjuntamente el trabajo.
Soy un gran admirador de la programación en pareja. Puedes llamar a esto “colaboración extrema”. Como desarrollador, mis habilidades crecen cuando hago pareja. Si soy más débil que mi compañero en el dominio o tecnología, claramente aprendo de su experiencia. Cuando soy más fuerte en algún aspecto, aprendo más sobre lo que conozco y no conozco al tener que explicarme. Invariablemente, ambos traemos algo a la mesa y aprendemos mutuamente.
En pareja, cada uno de nosotros llevamos nuestras experiencias de programación colectiva –tanto de dominio como técnica– al problema en cuestión y podemos aportar agudeza y experiencias únicas al escribir software efectiva y eficientemente. Incluso en caso de desequilibrio extremo en el dominio o conocimiento técnico, el participante más experimentado invariablemente aprende algo del otro –quizás un nuevo atajo del teclado o exposición a una nueva herramienta o biblioteca–. Para los miembros menos experimentados del par, es una gran manera de ponerse al día.
La programación en pareja es popular con, pero no exclusivamente a, promotores del desarrollo ágil del software. Alguien que se opone a la pareja sugiere: “¿porqué debería pagar a dos programadores para hacer el trabajo de uno?”. Mi respuesta es que, en efecto, no debería. Argumento que el emparejamiento incrementa la calidad, el entendimiento del dominio y tecnología, técnicas (como los trucos del IDE) y mitiga el impacto del riesgo de lotería (uno de tus desarrolladores expertos se gana la lotería y renuncia al siguiente día).
¿Cuál es el valor a largo plazo de aprender un nuevo atajo del teclado? ¿Cómo medimos la mejora global de la calidad del producto resultante del emparejamiento? ¿Cómo medimos el impacto de que tu compañero no te permita adoptar un enfoque sin salida en la solución de un problema difícil? Un estudio cita un incremento del 40% en eficacia y velocidad (J T Nosek, “The Case for Collaborative Programming”, Communications of the ACM, Marzo de 1998). ¿Cuál es el valor de mitigar tu “lotería de riesgo”? Muchas de estas ganancias son difíciles de medir.
¿Quién debería hacer pareja con quién? Si eres nuevo, es importante encontrar un miembro del equipo que tenga conocimientos. Tan importante como encontrar quien tenga buenas habilidades interpersonales y de entrenador. Si no tienes mucha experiencia del dominio, emparéjate con un experto.
Si no estás convencido, experimenta: colabora con tus colegas. Haz pareja en un problema retorcido e interesante. Ve cómo se siente. Inténtalo unas cuantas veces.
Traducción: Espartaco Palma