La importancia de la historia

Amo la frase "Dejó de andar. Y nosotros no tocamos nada" porque ha hecho que casi todo el mundo acepte la necesidad de la práctica de gestión de la configuración, cuyos beneficios van más allá de dar respuesta a esta frase. Además, claro, es una de las áreas del nivel 2 de CMMI, así que la tenemos que cumplir. La tenemos que cumplir, no se discute: no importa para qué, acá no se discute, la duda es la jactancia de los intelectuales (*): si lo dice CMMI hay que hacerlo.

Perfecto, lo hacemos. Y vamos a la definición de CMMI, que como todos sabemos explica, en un lenguaje accesible el significado de algunos términos criollos . (van solo los objetivos específicos, las prácticas y subprácticas se encuentran muy fácil por ahí)

• Se establecen las lineas bases (cuidado!!! no es el concepto de linea base de ITIL que es más o menos el que todos entendemos por linea base) de los productos identificados.
• Los cambios a los productos bajo gestión de la configuración son seguidos y controlados
• La integridad de las lineas base se establece y mantiene
  

Clarísimo, no?. Bueno, no para nosotros. Como siempre la pregunta ante esto es... "y que hacemos?". Después de un tiempo de discutir, van unos revolucionarios conceptos a los que llegamos:

• Tener versionado de código no es hacer gestión de la configuración: además tenemos que identificar los hitos o releases usando el versionador de una forma coherente y homogenea. Por ejemplo, teníamos que poder decir "volvamos a la versión que entregamos el viernes pasado". Pan comido, un sencillo mecanismo de tags y branches y listo.
• El código fuente en el versionador no es suficiente: he visto que hay una tendencia a no versionar los objetos de la base de datos. A veces, con suerte, llegamos a los stored procedures, pero no versionar ni tablas ni índices es lo habitual: después de todo no son código fuente, no?. Yo me atrevo a proponer una tesis subversiva: si no hay coherencia entre el código y los objetos de la base, existe cierta posibilidad de que la release sea fallida.
• Tenemos que saber que incluía cada revisión: que bugs estaban resueltos, cuales no, que funcionalidad implementada, que errores conocidos que íbamos a resolver en cada revisión. Para esto, necesitábamos algo más que un versionador de código. Había que adoptar un issue tracker e integrarlo con el versionador. Primero a mano, incluso ingresando la relación con los branches y tags a mano en el campo de descripción, después si se puede, se automatizará. ( Esto da pie a hablar del mejor argumento para impedir cualquier mejora: Pedir la perfección. Si uno no quiere hacer nada, puede atacar cualquier cosa que le propongan por no ser perfecta. Será motivo para otro post)
• Si algo había cambiado, teníamos que saber cuando había cambiado, ser capaces de elucidar las diferencias con la versión anterior y en lo posible, tener una noción de por qué había cambiado y el impacto. Esto estaba bien, no? Al fin y al cabo ya teníamos el versionador de código. Bueno, tampoco: esto incluye a los planes, descripciones técnicas y funcionales, algún que otro modelo (no soy un gran fan de modelizar todo y no me asusta la documentación de diseño desactualizada después de que el proyecto ha terminado, me inclino más por el modelado ágil, tema para otro post). Además de incorporar todo esto al versionador, usamos el issue tracker para conocer el momento, motivo e impacto de los cambios
• Deberíamos ser capaces de sacar una foto completa de una release. Esto es, no solo lo necesario para desplegar cualquier release por la que hayamos pasado (esto es código, scripts, objetos de la base, dtd, etc, etc, etc) sino especificaciones, reportes de bugs, scripts de pruebas y demás. De nuevo, no era difícil si subíamos todo (no solo el código) a un gestor de versiones y nos apoyábamos en el issue tracker.
  

La idea de tener aunque una descripción de los motivos del cambio levantó algunas discusiones sobre si era agil escribir el por qué de cada cambio importante (no, no hay una definición de importante. Aún no hemos encontrado un buen sustituto para la inteligencia, y espero que no aparezca). Mi postura fue que sí (o que si no era ágil, igual lo teníamos que hacer), basado en el siguiente argumento: si no está escrito no se puede revisar y aprender de ello (**), y necesitamos aprender de nuestra experiencia. Lo ágil, desde mi punto de vista, es no escribir más de lo necesario ( y cuanto es lo necesario? bueno, ver definición de importante más arriba).

Por supuesto que la frase "Dejó de andar. Y nosotros no tocamos nada" es cierta a veces (los tablespaces se llenan, los campos númericos se muestran cortos de un día para otro, bugs latentes salen a flote cuando se pasa determinada cantidad de información). También, como decía antes, la gestión de la configuración no solo da respuesta a esta frase. Incluso, el orden temporal no es necesariamente indicio de causalidad: que dos cosas hayan pasado en secuencia es prueba insuficiente de que la primera hay causado la segunda (o sea, la falacia post hoc ergo propter hoc. Motivo para otro post: falacias argumentativas)

No me propongo argumentar que la gestión de la configuración haya sido una respuesta a la costumbre de reportar errores usando esta frase, pero sí decir que donde han sufrido estas cosas es más fácil hacer ver la importancia de la gestión de la configuración.

Lo que me queda claro es que se agradece que haya gestión de la configuración cuando "dejó de andar. Y nosotros no tocamos nada". Primero, porque como diría el gran Dr. House, "todos mienten" (a propósito o sin querer, todos mienten). Y después, porque si estamos en alguno de los extraños casos donde efectivamente, ellos no tocaron nada, sirve corroborar tan sospechosa frase en los registros de gestión de configuración y comenzar a buscar campos que quedan chicos, problemas de memoria latentes que surgieron cuando se incrementó el volumen de transacciones, funcionalidad que hasta ese momento no había sido usada, un diseño deficiente de sincronización de transacciones que por obra y gracia del espíruto santo no había llegado a verse envuelto en la condición que lo hizo dispararse.


Ahá, muy interesante, pero con todo esto que nos explicaste vamos a cumplir con CMMI?. Sí?. Bueno, entonces hacelo y comprá el software que necesites, pero buscá el más barato.

Me encanta sentir que he cautivado a mi audiencia.


(*) Frase que ha pronunciado el filósofo Aldo Rico durante una rebelión carapintada. Algunos aseguran que fue Ortega y Gasset ( tan filósofo éste como el antes mentado) el autor original del a frase.
(**) No me imagino a un científico diciendo "Lo que ocurre es que yo no escribo papers porque hago ciencia ágil. Mejor que se siente el revisor al lado mío y le voy contando las ideas" (sí, como dije, considero la ciencia como paradigma de éxito en cuestiones intelectuales)