La semana pasada me vi envuelta en una situación un tanto cómica. En mi empresa (empresa que valoro mucho y realmente adoro 🥰) existen grupos de trabajo tematizados, transversales a los proyectos donde puede participar cualquier empleado, y uno de ellos es el grupo de inspección de código. Se me ocurrió preguntar en el chat abierto del grupo si alguien practicaba pair-programming o incluso mob-programming. La respuesta que me dio el fundador del grupo de trabajo directamente fue «No tengo constancia que se esté utilizando metodología pair/mob programming en la empresa. La verdad que duplicar recursos asignados a un proyecto no está alineado con la filosofía de la empresa.«.
Humm… ¡un reto!
Mi cara pasó de expresión risueña y expectante a poker face absoluta, jajaja. Pero he decir que no me sorprendió negativamente… Reconozco que estas cosas me las tomo como pequeños retos y posibilidades de cambio de enfoque a mi alrededor 😋. Tengo mucho cariño a mi empresa porque se preocupan por hacer bien las cosas, pero los pobres se quedaron anclados en la idea de que todos los proyectos salen bien solo si dedicas un buen porcentaje del tiempo inicial a estimar sin errores todo el conjunto y analizar tooooodos los requisitos de antemano. Solo así, las horas/hombre cuadrarán al cabo de 2 años (me acuerdo tanto del mythical man-month…).
Debatiendo sobre pair programming
Bueno, pues tras este gran momentazo, se me ocurrió proponer un debate distendido dentro del grupo de trabajo. Me interesaba saber qué opinaba más gente que hubiese allí. Así que, el fundador del grupo, muy amable, organizó ese debate unos días después.
Cuál fue mi sorpresa que no solo conocían los conceptos, sino que algunos miembros incluso ¡tenían ganas de probar eso del pair-programming! No había un sentimiento de rechazo general como yo me había podido imaginar en algún momento. En sus muchos años de desarrollo en la empresa no habían tenido la oportunidad de experimentar esta práctica porque nadie lo había iniciado, no veían oportunidad de probar, la inercia del día a día les comía…
Dejando a un lado la sorpresa grata de haberles prejuzgado mal, comentamos que uno de los mayores retos es cómo evidenciar los beneficios del pair-programming en un proyecto, sobretodo cuando los managers desconfían del método, ya que desde fuera lo que se observa es que dos personas escriben una sola cosa, y en la mente se les forma el interrogante enorme de: «¿y si cada uno escribiera su propia cosa?. Se harían dos cosas a la vez en vez de una, ¿no es ser eso más eficiente?».
Pero tengo suerte porque en esta empresa tienen muy interiorizado que la técnica de revisarse el código entre compañeros (Pull/Merge Request) es algo que funciona y que, de hecho, debe hacerse obligatoriamente en todos los proyectos. ¡Bieeen! Sentido común acude al encuentro. La concepción de que si otra persona revisa el código éste tendrá menos bugs ¡está interiorizada!. Por lo que pude introducir al debate: «Si cada persona escribe en soledad código, pero luego tienen que pedir a un compañero que se lo revise en asíncrono, ¿qué pasa con esos tiempos? Interrupciones, cambios de contexto, comentarios sobre comentarios… ¿No es ese un coste considerablemente alto?».
Y, además, juega más en mi favor que en esta empresa también se tiene muy interiorizado que cuanto antes descubras un bug en el ciclo de vida del proyecto menos coste tendrá.
Evidencia de los beneficios del pair programming
Volviendo al tema complicado de «cómo dar evidencia del beneficio del pair-programming al desarrollar»:
Es cierto que evidenciar estos beneficios es un tema difícil, y para sacar ideas, pedí ayuda a mi amiguete ChatGPT:
(ME) What could be the real evidences of success when practising pair programming on a project?
(ChatGPT) When practicing pair programming on a project, there are several tangible indicators of success that can serve as evidence:
- Improved code quality: Measure the reduction in defects or bugs discovered during testing or post-release. If pair programming is effective, you should see a decrease in the number and severity of defects reported.
- Faster development cycles: Monitor the overall project timeline or specific task completion times. Pair programming can lead to faster development due to immediate problem-solving, reduced rework, and shared knowledge, resulting in shorter development cycles.
- Increased productivity: Track the amount of work accomplished within a given time frame. Look for higher outcome, such as the number of user stories or features completed or delivered to production or tasks accomplished compared to previous projects or individual work.
- Enhanced collaboration and knowledge sharing: Observe the level of communication and collaboration between team members during pair programming sessions. Look for improved sharing of ideas, increased participation, and better knowledge transfer within the team.
- Higher developer satisfaction and morale: Conduct surveys or collect feedback from developers practicing pair programming. Measure their satisfaction levels, motivation, and engagement with the project. Higher satisfaction and morale indicate a positive impact of pair programming.
- Reduced integration and regression issues: Monitor the occurrence of integration issues or regression defects. Pair programming can help catch these issues early, leading to smoother integration and a decrease in the number of regression bugs.
- Learning and skill development: Assess the growth and development of team members’ technical skills and domain knowledge. Pair programming fosters continuous learning as developers share their expertise and learn from their peers.
- Team synergy and cohesion: Observe the level of teamwork and collaboration within the development team. Look for signs of improved cohesion, trust, and mutual support, which are often enhanced by pair programming practices.
Un pequeño experimento
Y para el primer punto (por empezar por algo), la empresa tiene un análisis de densidad de defectos en el código. Para ello, se toma nota de:
- número de líneas de código
- cuánto tiempo ha durado la revisión
- cuántos defectos se han encontrado
Así que se me ha ocurrido tomar nota de las sesiones de pair programming que hagamos en el equipo, a mano, en una libreta. La primera en la que lo he hecho ha sido esta semana:
- 3 desarrolladores
- 1 hora y media de programación juntos
- 6 potenciales defectos encontrados en tiempo real
- no sabría decir cuántas lineas de código, pero podría revisar las funciones/métodos de los archivos que vimos juntos y sumarlas
¿Creo que ha merecido la pena? Pues a ver… Si cada uno de nosotros hubiese estado 1,5h desarrollando en solitario, podríamos suponer que se hubiese generado el triple de funcionalidad (aquí se mide en líneas de código 😅), el triple de errores y sin corregir, no habríamos aprendido juntos de esos errores y encima necesitaríamos 3 Merge/Pull Requests en otro momento, cruzadas, para que otros de nosotros las mirásemos.
¿Entonces el pair programming es más eficiente?
Y para finalizar, ¿compensa entonces hacer pair-programming? ¿no compensa? Pues… como casi todo en esta vida, depende.
Para tareas quizás muy exploratorias, que no se sepa bien qué hay que hacer aún, que necesitan de investigación y mucho prueba y error previo… quizás venga bien trabajar individualmente. E incluso casos contrarios: tareas muy mecánicas, que ya se sepa que no elevan la complejidad del código, que se conocen bien por dentro por todo el equipo de desarrollo… pues quizás tampoco haga falta programar en pareja per se (aunque personalmente solo encuentro razones que justifican el sí hacerlo, aunque sea un rato, la verdad 🤓 – e ¡¡incluso hay empresas que trabajan en pareja siempre!!).
Pero en otras tareas donde se sepa claramente qué hay que conseguir, donde haya que crear nuevas clases, nuevos métodos, nuevas funciones… para pensar en los casos de tests juntos, para ponerles nombre a las variables… Ahí seguro que sí compensa.
En fín, que si la cuestión es que aún no lo has probado yo te animaría a que, como mínimo, lo pruebes.
***
Si te ha gustado el post y te interesa el tema de cómo introducir esta práctica en un entorno donde se desconoce, te recomiendo leer este paper de Alistair Cockburn y Laurie Williams del año 2000, que seguro te gustará: https://www.researchgate.net/publication/2333697_The_Costs_and_Benefits_of_Pair_Programming