Versionado maloliente (El arquitecto negador).

En este blog han salido castigados programadores, analistas, líderes de proyecto, usuarios... pero hay un participante del proceso de desarrollo al que no le he señalado ninguna falta (¿por qué será?)... el arquitecto de software.

El arquitecto es como un programador que piensa mucho, que ha programado muchísimo pero que ya no no lo hace demasiado y cada vez menos (a veces extraña). Su trabajo es más bien crear una estructura más o menos vacía que el resto del equipo irá completando con el conocimiento del negocio.

De esta manera, alejado del barro y el polvo de la obra en construcción, se mantiene impoluto mientras controla el avance.

En parte es cierto. Pero la arquitectura de software tiene su barro. Aparte de pensar y crear bonitos esqueletos el arquitecto tiene, entre otras cosas, que hablar con el líder de proyecto (o que soportarlo, o esquivarlo, depende el día), pelearse con analistas (con o sin razón), sufrir porque sabe que no llega "ni a ganchos", mirar el código y amargarse (porque es un obsesivo), llevar el versionado y el mantenimiento y organización general del sistema de control de código fuente, entre otras edificantes tareas.

Tarea ingrata esta última si las hay, sobre todo en un equipo donde hay muchos proyectos (que a veces nacen y crecen como hongos, de la nada y de cualquier manera), muchas cabezas organizadas de formas diferentes (todas ellas válidas) y en especial... muchas versiones. Esto último dependerá del negocio. En algunos negocios uno sabe con meses de anticipación la fecha de lanzamiento de una versión. En otros puede darse un viernes a las cinco de la tarde... con suerte se gana tiempo con un tímido "para el lunes".

Versionar y organizar es ingrato, repetitivo pero más o menos esporádico y muy susceptible a errores complicados de detectar y más aún de resolver.

Un error de diseño en un buen arquitecto es cosa de todos los días. Al fin y al cabo es un error de diseño, que si en general es bueno se compondrá con relativa facilidad. Un error de versionado... es más complicado de corregir, pero es un error aceptable. Lo mismo que al codificar, siempre se comete algún error (por minúsculo que sea) al versionar. Para eso se prueba.

Un error de procedimiento al organizar el versionado o el control de código fuente... es más duro de tragar. No es una distracción, no es un pequeño error en una larga serie de pasos... es el equivalente del rubro a ese código tan feo que al arquitecto le encanta debatir y enmendar o someter al escarnio público en blogs como éste (y que a todos les gusta ver, síndrome de "not in my code", que le dicen, o algo medio morboso que tenemos algunos programadores).

Porque hay veces en las que el arquitecto tiene que meter la mano en el barro, dar vuelta carpetas y proyectos que no tiene la menor idea de qué tienen adentro y rezar por que todo haya salido más o menos bien, ya que no puede probar todo eso y mucho menos decirle a nadie lo que acaba de hacer.

Como siempre Cerebrado es el mejor a la hora de proponernos situaciones "muy cercanas a la realidad", como la siguiente charla entre programador (P) y arquitecto (A). Vamos a repetir la exitosa fórmula de "Simpleton (un post a cuatro manos)", pero ahora escribe él y las itálicas son mías:

P (programador): -Moviste las carpetas del framework en el SourceSafe, nadie nos avisa nada y a nosotros nos quedan enlazadas las soluciones de nuestros proyectos a cualquier lado.

El tipo quería reorganizar eso a sabiendas de que necesariamente iba a dejar algún cabo suelto, pasó un tiempo y... nada, pensó que había zafado. Arma rápidamente una estrategia: negar.

A (arquitecto): -Si, pero me encargué de abrir todos los proyectos que referencian al framework y actualizarlos.

Es decir... bueno, los que el creía que referenciaban al framework de la manera en que deberían referenciarlo... suponiendo que todos hayan sabido hacer eso en su momento... al fin y al cabo él no es el encargado de asegurarse de eso... bueno, tal vez sí es el encargado, pero la vida del arquitecto es muy complicada.

P: -(¡¡WTF!!) Este... pero eso lo podés hacer cuando son pocos proyectos...

A: -¡Claro! Si todavía son pocos, creo que no más de 10. Te los puedo decir de memoria: (tira dos o o tres)... (carraspea)... ejem...

Aquí ya se empieza a dar cuenta de que metió la pata no una sino dos veces. La primera era inevitable, algún cabo suelto iba a quedar. La segunda pudo haberse evitado. Tendría que haber respondido "sí, ya sé, pero tenía que reorganizar eso y no quería armar un debate, a medida que encontremos los errores los voy corrigiendo, no está muy bien, pero por lo menos lo vamos ordenando". Amor propio, qué mal consejero. Estrategia alternativa: negar, negar y negar.

P: -Yo te puedo nombrar al menos 3 proyectos que vos ni sabés que existen.

A: -¡Pero eso está mal! ¡Me estás diciendo que hay 3 proyectos que andan dando vueltas por ahí y yo que soy el arquitecto no los conozco!

Un poco de distracción, de arena en los ojos, tal vez la charla deriva a esos problemas de comunicación tan frecuentes... Tiene razón, pero los proyectos estaban ahí, en **SU** control de código fuente.

P: -De acuerdo, está mal... pero también está mal que vos toques cosas que nos pueden afectar a todos y no informes de esos cambios.

A: -No está mal. Yo me hago responsable de lo que hago.

Avisar ¿yo? Si hago 10 refactories por día y nadie se entera porque el diseño (que es una obra de arte) lo permite. Tendría que haber pasado lo mismo con el movimiento de carpetas. Si hubo algún error es porque algo (que no es mi estructura) estuvo mal armado (es decir, no estuvo igual a mi estructura). La estrategia va bien. Sigamos con el plan: negar.

P: -Está bien que te hagas responsable, pero está mal.

A: -No.

Casi zafa, no va a dar el brazo a torcer... sólo hace falta negar un poco más.

P: -Sí.

A: -No.

P: -Sí.

A: -No porque blah blah blah (hace uso de su fantástica labia).

Saca las reservas: fundamento teórico, de ese que siempre dice que "hay que acomodar a la situación". Bueno, es verdad, éste es el preciso momento en el que el andamiaje teórico se acomoda a la situación... de nuevo.

P: -Sí.

Está pensando "Maldito programador obstinado... el tema es que éste ya olió sangre, no me va a soltar".

A: -Bueno, sí está mal, LO HACES IGUAL, porque en mi equipo somos n y hacemos ésto desde el principio, y estamos todos de acuerdo y (mas blah blah blah).

Es decir, la tuya "es una opinión y es válida"... pero acá mando yo. Y ya no voy a dar el brazo a torcer porque admitir que me equivoqué ahora es admitir que vengo negando como un nene al que lo descubrieron con la mano en la lata. Estrategia de refuerzo: negar negar y negar (cuando sólo tenemos un martillo todos los problemas son clavos).

P: -Ah (coma caca, millones de moscas no pueden equivocarse...).

A: -Lo que pasa es que para trabajar en equipo a veces en las que hay que acatar.

Argumento irrefutable que no se aplica a este caso (ya que el programador nunca hizo nada en contrario de nada, sólo cuestiona).

P: -Mirá que buena que está esa flaca...

A: -Uh, me la perdí.

Y como no se puede razonar un argumento basado en el autoritarismo, el programador prefiere hablar de mujeres. Al fin y al cabo conoce al arquitecto desde hace un tiempo y sabe que cuando se enoja es que sabe que no tiene razón.