¿Qué es la programación en parejas?
La programación en parejas es una práctica ágil donde dos personas trabajan en una sola computadora para resolver un problema. La programación en pareja abre un canal de comunicación y retroalimentación inmediata entre dos personas, para analizar, diseñar, probar y crear una solución utilizando código de programación.
¿Cuántas veces no hemos necesitado ayuda para resolver un problema?
¿Para lavar los trastes? – Oye, dejaste jabón en esa parte, – El plato tiene una manchita ahí.
También cuando manejamos un automóvil, nuestro copiloto nos dice:
- Dobla a la derecha, este camino es más corto.
- ¡Aguas de este lado viene carro! ¡Ahí hay un bache!
Aquí es donde otra persona y dos ojos más entran en acción.
Las grandes cosas vienen en parejas
De izquierda a derecha y de arriba hacia abajo:
- Bill Hewllet and Dave Packcard. Fundaron HP
- Robert Noyce y Gordon Moore. Fundaron Intel
- John Lennon y Paul McCartney, al escribir las canciones, uno empezaba una frase y el otro lo completaba y viceversa, según Collaborative Circles: Friendship Dynamics and Creative Work
- Pablo Piccaso y George Braque, cada pintura solo estaba terminada si ambos estaban de acuerdo, durante su trabajo en pareja cuando crearon el cubismo según Powers of Two: Finding the Essence of Innovation in Creative Pairs
- Steve Jobs y Steve Wozniak. Fundaron Apple
- Larry Page, Serguéi Brin. Fundaron Google
- Paul Allen y Bill Gates. Fundaron Microsoft
Origen de la programación en parejas
Año 0
Desde un inicio, desde que existe la interacción social, siempre se busca simplificar las tareas y hacerlas con la mejor calidad posible. Como vemos en la sección anterior, el trabajo en pareja siempre ha existido y da muy buenos resultados.
Un cazador enseña a su hijo como cazar una cebra y le indica que el mejor lugar para clavarla es justo debajo de la oreja, donde puede atravesar su cráneo, pero ese es un tiro muy difícil. El tiro más fácil es – “Apuntar a las rayas que la cebra tiene en el pecho” (mientras dibuja las rayas en el tronco de un árbol).
– “Sigue practicando el tiro a una distancia de 20 pasos hasta que claves la lanza correctamente”, luego -“No espera, sostén la lanza así”, más tarde – “Si, así está mejor, continua así” … – “Ahora, pídele a tu tío que te enseñe cómo hacer que la cebra se acerque a una distancia de 10 pasos”
Bob Allen de codecraftsmansaturdays
Programadoras de ENIAC, 1946
Betty Snyder y yo, desde el principio, éramos una pareja. Y creo que el mejor diseño y todas esas cosas son hechas en pareja porque mutuamente se puede criticar, identificar errores y usar las mejores ideas de ambos.
Betty Jean Jennings Bartik, ENIAC programmer 1946
Jean Bartik formó parte de las ahora justamente reconocidas primeras programadoras de ENIAC, donde según fuentes también practicaban “Test First development”.
Frederick Phillips Brook, 1953
Fred Brook, autor del libro The Mythical Man-Month: Essays on Software Engineering del año 1975, un libro sobre ingeniería de software y administración de proyectos. También conocido por la ley de Brook, la cual empezó a definirla cuando trabajaba para IBM en el desarrollo del sistema operativo OS/360. En este libro él menciona lo siguiente:
Agregar mano de obra a un proyecto de software retrasado, lo retrasa aún más.
Frederick Phillips Brook
Brook le escribió a Laurie Williams:
Compañero de posgrado Bill Wright y yo probamos por primera vez la programación en parejas cuando era un estudiante graduado (1953 -1956). Produjimos 1.500 líneas de código libre de defectos; se ejecutó correctamente en el primer intento.
Frederick Phillips Brook
Richard P. Gabriel en 1972
1972-1973, Dick Gabriel hace programación en pareja con Jonl White, usando Lisp como lenguaje de programación. Después como encargado del desarrollo de Common Lisp, programación en parejas fue una de las prácticas principales.
Dynamic Duos, 1978-1988
Larry Constantine
Patron organizativo “Developing in pairs“, 1995
James Coplien
“Las personas a veces sienten que pueden resolver un problema solo si tienen ayuda. Algunos problemas son más grandes que los de cualquier individuo”. La solución propuesta del patrón organizacional es “emparejar diseñadores compatibles para trabajar juntos; …
James Coplien
El proyecto Pasteur extrajo muestras empíricas de 50 organizaciones de desarrollo de software altamente efectivas, usando técnicas de análisis y recopilación de datos similares a las usadas por sociólogos y antropólogos.
Extreme Programming
, Kent Beck 1998
, Kent Beck 1998Finalmente Kent Beck, unos de los firmantes del manifiesto ágil, creador de programación extrema y de sus propias palabras, el “redescubridor de TDD” en 1998 agregó “pair programming” como una de las prácticas de Extreme Programming.
Beneficios de programación en parejas
Todos los beneficios de más abajo se resumen en los tres principales aquí listados, que desde el punto de vista de negocio, son el objetivo de implementar cualquier práctica ágil.
- Disminuir los tiempos
- Reducir el Estrés
- Aumentar el Dinero o las ganancias
Además estos beneficios son el resultado de aplicar los siguientes principios ágiles:
- Individuos e interacciones sobre procesos y herramientas.
- Respuesta ante el cambio sobre seguir un plan.
- Software funcionando sobre documentación extensiva.
Canal de comunicación y colaboración
Se abren muchos canales de comunicación (más si se rotan las parejas) que estimulan la colaboración. Si combinamos diferentes perspectivas, ideas, conocimiento técnico y conocimiento del negocio, entonces el resultado es una solución superior, una solución más simple y más sólida. Sin mencionar que el tiempo en llegar a una solución se reduce considerablemente.
Muchísimas veces ni siquiera tenemos que esperar a que nuestra prueba falle o esperar a debuguear para notar un error, nuestro compañero con su lindo cerebro y sus dos ojos nos lo puede indicar de inmediato.
Incluso ni siquiera tenemos que recordar la especificación del problema a resolver (por eso de la pérdida de enfoque), porque tenemos otra mente que nos lo recuerda.
Code Review Continuo
Cuando se está programando en pares se obtiene retroalimentación inmediata de nuestro compañero, vamos a llamarle “code review instantáneo”. Así que actuamos ante ese cambio de idea, perspectiva, mejora, error cometido, cualquier cosa que nos ayude a resolver el problema o mejorar la solución.
- Te falta un punto y coma.
- ¿No te falto definir la variable que contiene los datos de tu parámetro?
- Ahí debe ser un string no la referencia al método
Son frases que he escuchado mucho antes de ejecutar la verificación de la prueba, el feedback o review lo obtengo aún mucho más rápido que la prueba automatizada. Esto en realidad es un ciclo de retroalimentación más eficiente.
Esparcir el conocimiento técnico y de negocio
- Transferencia de conocimiento, siempre existe algo que aprender del compañero, tanto del entendimiento del problema y el negocio, como técnicamente.
- Esparcimiento y homologación del estándar y estilo de programación definido por el proyecto.
- Si un integrante del equipo se va, no importa, todos los demás tienen contexto y el conocimiento adecuado.
- Mucho menos tiempo descubriendo lo que hizo el excompañero
- Los nuevos integrantes del equipo obtienen el conocimiento y el contexto rápidamente de los compañeros con más tiempo en el proyecto, preguntando y haciendo programación en parejas.
Aumento en la calidad del producto
Si solo armas lo primero que piensas, nunca tendrás tiempo para pensar en una segunda cosa mejor.
Kent Beck
- Diferentes perspectivas que ayudan a encontrar una solución mucho más simple. Esto significa menos tiempo desarrollando, las soluciones simples son mucho más sustentables, es más fácil comprenderlas, implementarlas en otros lugares/casos, modificarlas y mejorarlas. Siguiendo el principio ágil de “Simplicidad, el arte de maximizar el trabajo no realizado”.
- Combinación de ideas y creatividad para mejorar la solución. Casi siempre el desarrollo de cualquier cosa que usa dos mentes, resulta en un diseño superior. Y este punto se relaciona mucho con el siguiente principio ágil. “La excelencia técnica y el buen diseño, mejoran la agilidad”.
- Utilizar cada pieza del sistema como una verdadera caja negra, debido a un diseño superior creado por dos mentes, porque es simple y de mayor calidad, nos ahorra tiempo revisando los cables detrás de una funcionalidad. Nos permite enfocarnos en el problema y no como funcionan las piezas necesarias.
- Disminuye la necesidad de documentación en etapas tempranas de desarrollo. Por que el conocimiento se esparce, la documentación pierde sentido en etapas tempranas, una documentación solo funciona cuando se tiene una versión muy estable de una pieza de software, no queremos perder el tiempo en modificar la documentación cada vez que cambiamos algo en el código.
- Lo recomendado es invertir ese tiempo en tener un conjunto de pruebas automatizadas y claramente diseñadas, enfocándose en transmitir de manera transparente los requerimientos, que sean fácilmente entendidos en la primera lectura. No necesitamos documentación que nos dé una especificación desactualizada o errónea. Al hacer pruebas y mejor aún, “test-first developement” en pareja, aumenta considerablemente la calidad.
Ahorra tiempo, mayor velocidad
En lugar de pasar una hora atorado haciendo una tarea individual, en pareja muchas veces lo resuelven en cinco minutos. ¿Nunca te ha pasado que estás atorado durante dos horas, luego te vas a dar una vuelta, regresas y en menos de cinco minutos encuentras la solución? Pues en pareja no necesitas esperar esas dos hora e irte a dar una vuelta, tu compañero podría tener la solución o conversándolo con él en conjunto cristalizan una aún mejor.
El tiempo que te sobra lo ocupas para todavía hacer más.
Debido al beneficio de esparcir el conocimiento, aceleramos el nivel técnico y de negocio de los nuevos integrantes.
Por el aumento de calidad ya explicada, las integraciones son más rápidas, se resuelven, es más rápido modificar funcionalidades e implementar nuevas por la simplicidad de las mismas.
Reduce el Estrés
Entre menos tiempo pases trabajando tendrás menos estrés y una mente fresca y creativa (comprobado científicamente). Por lo cual tus tareas las resolverás más rápido, con ganas y con orgullo. Tendrás más tiempo después de tus horas de trabajo para estar con la familia, con la novia o esposa, o simplemente hacer tus cosas personales
Ahorra dinero
Es bueno para el negocio, entregas más rápidas, iteraciones con mayor alcance y por supuesto mejor retorno de inversión por la calidad del software y la flexibilidad de adaptarse a las nuevas necesidades del usuario final (por el diseño superior creado en pareja).
¿Como hacer programación en parejas?
Existen varias formas de usar la programación en parejas, los más usados y simples son:
- Driver y navigator
- Ping Pong
Driver y navigator
- Se tiene dos perspectivas en cuanto al código.
- El driver es la persona que controla la computadora y escribe el código, el navigator sentado a su lado observa el proceso desde otra perspectiva, revisando cada línea de código mientras el driver escribe, al mismo tiempo que apoya al driver dándole dirección y desbloqueándolo.
- Una persona se encarga de la táctica (driver) y la otra de la estrategia (navigator).
Es importante cambiar los roles continuamente, así mitigamos el aburrimiento y cambiamos de perspectiva para tener ideas frescas.
El navigator puede anotar sus ideas para no cortarle la inspiración al driver, estas ideas se pueden mencionar cuando el driver termine de escribir el código que tenía en su mente.
Neurociencia, dos modos de pensamiento
Según la neurociencia, la programación en parejas une dos tipos de pensamientos. El driver trabaja en un modo de pensamiento enfocado, mientras que el navigator trabaja con un modo de pensamiento difuso.
Porque ahora tenemos dos mentes, podemos separar estas dos perspectivas y utilizarlas al mismo tiempo.
Ejemplo de esto es lo que ya comentamos, cuando estás atorado con un problema por dos horas, te vas a dar una vuelta, tomar café o algo y regresas, te sientas enfrente de tu computadora y en cinco minutos lo resuelves.
Ping pong
- El primer developer escribe la próxima prueba
- El segundo developer hace pasar la prueba y escribe la próxima prueba
- El primer developer hace pasar la prueba
Después de que alguno de los programadores hace pasar la prueba, ambos hacen el refactor utilizando driver y navigator.
Esta es una técnica bastante sencilla y útil para cambiar frecuentemente entre driver y navigator, así ambos programadores practican ambos modos de pensamiento. Fomenta la creatividad y el uso de prácticas ágiles como TDD y BDD.
¿Cuánto cuesta hacer programación en parejas?
Uno puede pensar que el costo de hacer programación en parejas es el doble debido a que dos personas trabajan para completar una sola tarea, pero no es así, según estudios realizados por Laurie Williams en el año 1999 en la universidad de Utah, haciendo programación en parejas solo aumentó un 15% de tiempo para completar la tarea.
Ese 15% de tiempo gastado fue recuperado en un código con 15% menos defectos.
Según este estudio el código generado individualmente es 15 veces más costoso debido al mayor esfuerzo de arreglar los defectos. Luego si ese defecto se filtra a producción, entonces el costo es 60 veces más.
¿Por qué es más costoso el desarrollo con programadores individuales? Porque el diseño individual es inferior a un diseño creado por dos personas. Dos cabezas son mejor que una.
Este resultado se alinea con la filosofía de prevención de incidencias y que entre más tiempo pasa en encontrar el defecto, es más costoso porque primero se tiene que volver a replicar, entender el problema, entender el código relacionado y además el tiempo gastado en la solución. ¿Qué pasa si es un defecto que se detecta después de un año? ¿Qué pasa si la persona con más conocimiento del contexto ya no está en el proyecto o no está disponible?
¿Y si tenemos un equipo distribuido? ¿Cómo hacemos programación en pareja?
En la actualidad existen muchas aplicaciones de videollamadas para compartir pantallas, IDEs con extensiones o plugins y hasta aplicaciones para compartir el control de tú maquina que te permiten tener una colaboración en tiempo real sobre el código en cuestión.
Compartir pantalla:
Compartir código estilo google docs:
Compartir la máquina completa
¿Quién hace programación en pareja?
Empresas que hacen programación en parejas
- Spotify
- Shopify
- Thoughtworks
- IBM
- Microsoft
- Atlassian
Programadores que hacen programación en parejas
Jeff Dean y Sanjay Ghemawat. Super reconocidos en google porque salvaron a la empresa de morir, arreglaron el enorme crawler de google que había parado de funcionar en el año 2000. Han creado juntos en google a mapReduce, BigTable y Spanner. Y muchas cosas más fuera de google.
Kent Beck (Co-creador principal de extreme programming) y Erich Gamma (co-autor del libro Design Patterns: Elements of Reusable Object-Oriented Software). Juntos crearon JUNIT el principal framework de automatización de pruebas para Java y también para Kotlin.
Alistair Cuckborn. Creador de la familia de métodos Crystal clear y Heart of agile
Ron Jeffries. Firmante del manifiesto ágil y co-creador de extreme programming
Ward Cunningham. Firmante del manifiesto ágil y co-creador de extreme programming
Martin Fowler. Firmante del manifiesto ágil y autor del libro Refactoring: Improving the Design of Existing Code
Robert C. Martin. Firmante del manifiesto ágil y conocido por acuñar los principios de diseño SOLID
Michael Feathers. Autor del libro Working Effectively with Legacy Code
No todo es color de rosa en la práctica
¿Cuándo no hacer programación en parejas?
- Si la tarea es demasiada sencilla o algo repetitivo.
- Cuando ninguno tiene mucho conocimiento del problema y/o código a modificar.
- Mejor ambos se asignan tareas de investigación para retroalimentarse después y compartir ese nuevo conocimiento.
- Cuando uno de los pares ya pasó mucho tiempo haciendo programación en parejas. Continuar haciéndolo por mucho tiempo es demasiado desgaste mental.
¿Cuánto tiempo hacer programación en parejas?
Definitivamente no 8 horas al día, mucho tiempo haciendo programación en parejas es muy cansado, según fuentes lo recomendado es de 1.5 a 4 horas diarias.
¿Qué tan a menudo cambiar de pareja?
Cada vez que se sienta la necesidad según el problema a resolver. Se recomienda cambiar de pareja diariamente para esparcir el conocimiento técnico y de negocio, pero si alguien aún no entiende un concepto con su pareja actual, entonces no debería cambiar de pareja hasta que tenga sólido ese concepto.
Recomendaciones de interacción social
Super importante tener como base siempre estos tres principios humanos latentes en cada momento para las interacciones sociales.
- Respeto, de hecho un valor de scrum y extreme programming.
- Honestidad, alineado con la transparencia del empirismo de scrum y el coraje en extreme programming.
- Justicia, es justo pensar en el bienestar de todas las personas involucradas. Da el coraje (otro valor de scrum y XP) de hacer programación en pareja y buscar acuerdos mutuos. Al mismo tiempo te hace pensar en lo más justos para ambos, como pareja.
Las personas importan
Piensa en tu compañero, lo más importante son las personas, actua de la forma mas justa posible para entablar comunicacion y acuerdos.
También ponte en los zapatos de los usuarios finales, ¿Querrías tener problemas si fueras tú el que usa la aplicación? Esto ayuda a tener una mente positiva y darnos el coraje de hacer pair programming por el bien de todos. Genera Compromiso y justicia hacia los involucrados.
Tres hábitos para la comunicación y no estancarse.
- Piensa en ganar/ganar. A veces puede haber conflictos de ideas, piense en lo más importante, las personas, todos pueden salir ganando, en lugar de perder mucho tiempo debatiendo ¿Por qué no prueban ambas ideas? Paso a paso se darán cuenta de lo mejor para el problema o muchas veces son una combinación de las dos posturas.
- Procura primero comprender y después ser comprendido.
- Cuando se debaten ideas debemos entender profundamente la otra idea, escuchar con la verdadera intención de comprender. Un buen doctor primero hace un diagnóstico antes de dar una receta.
- Ahora tu turno de exponer tu idea.
- Sinergizar. Encontrar la solución juntos, tu idea en combinación con la mía genera una mejor, 1 + 1 = 3, 4 o 5, de esas dos ideas sale una tercera, una superior.
Reitero, si el debate sobre las ideas se está alargando, es mejor elegir un término medio y empezar a tirar código, conforme avancen verán por cuál idea se inclinan más.
Planifica
Tengan un horario de sesiones, con el objetivo de no solaparse con reuniones importantes. Con tu familia establece acuerdos y horarios para que tampoco te interrumpan a menos que de verdad sea algo importante.
Por ejemplo, si tu hijo quiere que juegues con él en el momento de la sesión de pair programming, aunque de verdad yo creo que jugar con tu hijo es más importante que trabajar, también podrías establecer con tu hijo los horarios de juego para que no se solapen con los horarios de trabajo.
Sin distracciones
Sin distracciones mientras se hace pair programming, respeta el tiempo de tu compañero y mantente enfocado en lo que están haciendo juntos, no leas emails, no veas mensajes de WhatsApp o de Facebook, trata de no hacer llamadas. Así eres justo con el tiempo de la otra persona.
Pomodoro
Es bueno tomar breaks cada veinticinco minutos o más dependiendo como se sientan y utilizar de cinco a diez minutos como recompensa para ahora si hacer lo que quieran, como revisar Facebook o el WhatsApp. Esto disminuye la fatiga y mantiene las ideas frescas porque constantemente te recompensas y le dices a tu cerebro que los próximos veinticinco minutos valen la pena.
Apertura
Mucho, mucho respeto a las ideas de tu compañero, no importa si tienes más experiencia o menos, recuerda que diferentes ideas y perspectivas nos llevan a mejores soluciones. El genio John Von Neumman pedía constantemente a sus compañeros que revisaran su trabajo.
Piensa en la crítica como algo que te ayude a mejorar.
Elimina el condicionamiento social
Normalmente se tiene la idea de que equivocarse es malo, de que no saber es herejía, al contrario, ser vulnerable en estos aspectos ayuda mucho a mejorar como individuo, como equipo y a mejorar el producto. Y todo el mundo debe estar consciente de esto, a no juzgar y abrazar las diferencias, las cuales son muy importantes a la hora de innovar porque diferentes perspectivas siempre nos permite construir una mejor forma de ver las cosas, lo que lleva a generar mejoras ideas y aumentar la creatividad.
La importancia de Celebrar
Celebren juntos después de terminar con una tarea, vayan a tomar un café, coman algo, jueguen un videojuego, que sé yo, el chiste que celebren. Esto promueve un mini team building y entrenan a su cerebro para no cansarse y tener pensamientos positivos para continuar. Ayuda al estrés.
De programación en parejas a Mob programming
Es una práctica ágil moderna que extiende la idea de pair programming a todo el equipo, donde se puede incluir todo tipo de involucrado en el producto. Desde programadores, administradores de base de datos, gente de diseño y experiencia de usuario, product owners, project managers, hasta clientes y usuarios.
Toda la gente brillante trabajando en lo mismo, al mismo tiempo, en el mismo espacio, en la misma computadora
Woody Zuill
Mob Programming es integración continua para ideas.
Joshua Kerievsky
Referencias
Foto principal por Alvaro Reyes de Unsplash
https://www.computerhistory.org/revolution/birth-of-the-computer/4/78/2258
https://www.oreilly.com/library/view/making-software/9780596808310/ch17s01.html
https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge
Powers of Two: Finding the Essence of Innovation in Creative Pairs
Collaborative Circles: Friendship Dynamics and Creative Work
ES_MX 
EN