[13 de 97] Hacer commit y correr, es un crimen.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Hacer commit y correr, es un crimen."

Niclas Nilsson.

Niclas es cofundador de la empresa factor10 y es editor en la comunidad de arquitectura en el sitio InfoQ.
Su blog es: http://niclasnilsson.se

[NT. El título original del axioma es: Commit-and-run is a crime.]

Aqui parte importante del axioma:

It's late in the afternoon. The team is churning out the last pieces of the new feature set for the iteration, and you can almost feel the rhythm in the room. John is in a bit of a hurry though. He's late for a date, but he manages to finish up his code, compile, check-in and off he goes. A few minutes later, the red light turns on. The build is broken. John didn't have time to run the automated tests, so he made a commit-and-run and thereby left everybody else hanging. The situation is now changed and the rhythm is lost. Everybody now knows that if they do an update against the version control system, they will get the broken code onto their local machine as well, and since the team has a lot to integrate this afternoon to prepare for the upcoming demo, this is quite a disruption. John effectively put the team flow to a halt because now no integration can be done before someone takes the time to revert his changes.

This scenario is way too common. Commit-and-run is a crime because it kills flow. It's one of the most common ways for a developer to try to save time for himself, that ends up wasting other peoples time and it is downright disrespectful. Still, it happens everywhere. Why? Usually because it takes too long time to build the system properly or to run the tests.

This is where you, the architect, come into play. If you've put a lot of effort into creating a flexible architecture where people can perform, taught the developers agile practices like test-driven development and set up a continuous integration server, then you also want to nurture a culture where it's not alright to waste anybody else's time and flow in any way. [ ...... ]

Invest time in making the system fast to work with. It increases flow, lessens the reasons for working in silos and in the end makes it possible to develop faster. Mock things, create simulators, lessen dependencies, divide the system in smaller modules or do whatever you have to. Just make sure there's no reason to even think about doing a commit-and-run.

---

Sí, ¡¡¡ es un crimen !!! y quizá no en el sentido legal de la definición, pero sí en un sentido moral.

Me desviaré un poco del tema principal del axioma para comentar (y quizá externar algunas ideas a manera de terapia) algunas reflexiones que surgieron durante una plática con Javier Castañon durante la 8a reunión de las comunidades SpringHispano, JavaMéxico y Grails-MX.

La plática en general trataba sobre administración de proyectos y,  durante la charla, Javier mencionó tres puntos que considera primordiales para que se pueda gestionar adecuadamente un equipo de trabajo:

• Comunicación
• Transparencia
• Rendición de cuentas.

Seguramente lo que se comentó durante esa charla servirá para más reflexiones, pero, en esta ocasión, retomo solo ese comentario.

De los tres puntos mencionados, considero el primero el más importante; el tema de la transparencia me parece también importante, pero, quizá por razones de supervivencia, creo que a veces y sólo a veces es necesario quedarse con algo para uno mismo (Sun Tzu tiene la culpa de que piense así ) y sobre la rendición de cuentas no tengo mucho que decir... para nadie es secreto que considero altamente probable la existencia del  karma   ;)

La transparencia puede verse en este ejemplo justo en el momento que el build se rompe y le llega a Jhon y al líder del proyecto un e-mail indicando que su commit ha roto el build. La rendición de cuentas llegará el día en que se haga pública la lista de "quienes han roto mas veces el build"; pero, parece que el ejemplo del axioma podría bien servirnos como  ejemplo de qué es lo que ocurre cuando la comunicación falla (Jhon pudo haber avisado que tenia un compromiso y, haber hecho el commit y las pruebas con tiempo).

Independientemente de las reflexiones que salgan del axioma, creo que situaciones como las que se comenta arriba ni siquiera alcanzan la primera agravante de ley (premeditación), y mucho menos llegan a las otras dos (alevosía y ventaja), cuando cada elemento del equipo tiene la conciencia, responsabilidad y compromiso; primero, con su trabajo y, si quiere, después con el equipo.

---

A propósito de temas relacionados con  la administración de proyectos, hay un post (con todo y fe de errata) de José Manuel Beas llamado:  Liderar mediante el ejemplo. De lectura recomendable.

Ahora sí, retomando el axioma... Nilsson deja muy claro el porqué debemos considerarlo un crimen: "rompe el flujo de trabajo de todo un equipo" y miren que mis lapsus pesimista me hace pensar que ese efecto puede ser el menos complicado, quizá no sólo se altera el ritmo de trabajo, sino que  incluso pone en riesgo una fecha de entrega (sí, ya le metí drama al asunto XD ).

Nilsson  menciona que, probablemente el tiempo o la "ruta/mecanismo de ejecución" de esas pruebas hacen que el "sospechoso-en-potencia" decida, con el objetivo de ganarse unos minutos, omitirlas.

¿Qué hacemos entonces para evitar caer en estos escenarios que (perdón por la insistencia y el drama pero, como decimos en México: cada quien platica, según como le fue en la feria.) pueden tener efectos serios en todo el equipo del proyecto?

Nilsson lo tienen claro; tener una "cultura de pruebas" puede ser el inicio de la solución; a mi parecer: ya no pensemos siquiera en  automatizadas, el sólo hecho de comenzar a crear la conciencia de que debemos probar adecuadamente nuestro código antes de hacer commit puede ser un excelente inicio.

En estos momentos, con las facilidades que nos dan algunas herramientas de integración creo que tenemos solucionado parte del problema.

Resumiendo:

El problema.
1. Hacer commit (sin hacer las debidas pruebas) es un crimen ya que mata el flujo(de trabajo de todo el equipo).... y en casos un tanto desafortunados puede generar efectos secundarios más complejos.

Parte de la solución:
2. Crear una cultura de pruebas y un  ambiente de desarrollo/construcción/despliegue (recomiendo este interesante post de Julio Cesár Pérez Arques sobre un ecosistema de software)  que permita que el desarrollo y proceso de build sea ágil y seguro.

El objetivo:
3. Asegurarnos que; del lado del proceso de desarrollo/construcción/despliegue del producto no exista nada que permita o incentive ese apócrifo pensamiento: "Haz commit y salte corriendo".

¿Se nos ha pasado algo?

Bueno, dejemos.... una vez más que Dilbert nos haga iniciar bien la semana.






---

Saludos a todos!!
RuGI
Isaac Ruiz Guerra.

Posted at 02:43AM ago 23, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[7]