Una clase sobre buenos modales.

De vez en cuando una clase llega exactamente a donde tenía que llegar en el momento preciso. La mayoría de las veces si uno quería dar clase sobre "A" termina dando sobre "a" que se le acerca bastante, pero no era lo que uno quería enfatizar.

Hoy llegué justo al centro de una de las cuestiones más importantes del desarrollo de software, y quiero aprovechar que tengo fresco el camino. Antes es obligado agradecer a los alumnos por las preguntas y comentarios precisos en el momento justo. Gracias.

Comenzamos desarrollando un ejercicio enunciado - diseño - codificación que venía de la semana pasada. Es un pequeño sistema de liquidación de sueldos. Diseñamos sistema con un gráfico (DFD nivel 1). Voy rumbeando hacia el diseño final, que era bastante elaborado, no por lo complejo sino justamente por su simpleza.

Así que luego de un largo rato tenemos el diseño completo y pasamos a la codificación.

Codificamos una parte de un procedimiento del sistema, casi un boceto. Cuando está más o menos terminado digo la típica y odiada frase "termínenlo para la semana que viene y vengan con las dudas y problemas que se les hayan presentado. Por ejemplo acá faltan datos, tienen que agregarlos de alguna manera. ¿Cómo harían para obtener los datos del empleado y mostrarlos en el recibo de sueldo?".

Momento de tensión. Surgieron dos posibilidades, creo que yo sugerí una (seguramente la que no me gustaba, viejo truco) y alguien tiró la otra. Lo importante es que ambas funcionaban y parecían simples. Impulso una votación.

Esto es lo importante: una de ellas implicaba un cambio en el diseño, mientras la otra lo seguía. Recordemos el momento: ya habíamos cerrado el diseño hacía bastante tiempo. Eligieron la que cambiaba el diseño. Suerte para mí, porque me dio pie para el sermón.

"¡¿Por qué eligieron esa?! Me rompieron el diseño, estaba tan bonito, tan cerrado, ¿no estábamos todos de acuerdo?".

Y ahí empezó el cierre final, que fue muy bueno. Voy a trasladar los conceptos centrales:

Obviamente en un ámbito académico todos estamos aprendiendo, así que en ese contexto es un error. En la vida profesional elegir esa opción no es un error, sino una falta grave que merece castigarse físicamente. ¿Por qué tanto?

Durante el desarrollo del software, en algún momento se establece un diseño. Su elaboración será más o menos participativa, más o menos consensuada entre los miembros del equipo, o será impuesto autoritariamente. Pero se establece. Y punto. Si no nos gusta, ése era el momento de dar pelea, y si la dimos y perdimos, perdimos. Luego taza taza cada uno a su casa y a codificar.

Cuando codificamos debemos seguir el diseño a rajatabla. En la práctica, eso indica básicamente que si el módulo que me ha tocado tiene determinadas entradas y salidas y ciertas formas establecidas de comunicación con "el exterior" tengo que respetarlos. Dentro de él soy amo y señor, pero ésos son mis límites.

La modularización, el encapsulamiento de la funcionalidad, es lo que permite distribuir tareas en un desarrollo, y aunque parezca raro, es lo que permite que cada uno codifique a su manera al establecer límites para la creatividad, evitando que lo que uno haga rompa el código del otro.

Así enunciado, parece una regla social al estilo de "mis derechos terminan donde empiezan los de los demás" y algunos programadores cometen el error de interpretarlo de esa manera, como una cuestión de "urbanidad" que puede estirarse un poco. No es así. No es una regla social, y no puede estirarse. Si no trabajamos de esta manera, no funciona. Simplemente, nuestro software se romperá en mil pedazos al intentar integrar partes que no encajan. Una computadora integrando partes de un sistema no "estirará" sus reglas para hacer que el sistema funcione, así que debemos ser tan estrictos como ella al respetarlas.

La regla básica que se aplica a un programador es la misma que se aplica a su código: debe hacer lo que tiene que hacer, o dar un error. Pero nunca, **nunca** hacer otra cosa, que será una respuesta inesperada. Tenemos que respetar el diseño o preguntar, avisar, invocar una reunión, hablar con el diseñador, lo que corresponda en cada caso. Pero nunca, **nunca** hacerlo de otra manera.

Si el programador avisa, se tomarán decisiones. Que pueden ser del tipo "rompamos con todas las reglas y hagamos que esto funcione, después vemos". Pero en alguna medida se evaluará el impacto sobre otras áreas del sistema, y se guardarán precauciones (o no), pero la instancia de comunicación es imprescindible. El programador debe saber cuándo lo que hace **puede** afectar al resto del sistema, aunque no sepa en qué manera lo hará o si lo hará realmente. Esto lo vuelve confiable.

Y llegamos al nudo central, que veo que se viene repitiendo en varios post relacionados con equipos de desarrollo. La comunicación y la confianza.

Viniendo de un programador con cierta experiencia, una mala decisión de este tipo es un error grave, y es más grave si de alguna manera denota que no es consciente de cómo sus acciones afectan al sistema que desarrolla junto con otros. Este tipo de "malas decisiones" generan desconfianza sobre el trabajo que se le puede asignar a un colaborador, porque nos indican que no podemos estar seguros de que lo haga en una forma que sea útil desde el punto de vista del sistema completo. De nada sirve que el código funcione bien si no puede integrarse al resto del sistema.

El momento de las integraciones es uno de los momentos finales en el desarrollo y es en general un momento de nerviosismo, de apuro, donde si no estamos sobre la fecha es que ya se nos ha pasado. Es un **muy** mal momento para enterarse de que una parte importante del producto genera errores al ubicarse con las demás, porque para el "integrador", que ve a los módulos como piezas que deben encajar unas con otras, este tipo de errores genera una infinidad de problemas que no puede resolver porque no conoce el contenido de cada módulo. Y si el error es grave puede que no haya forma de "encajarlo" en los tiempos requeridos.

Es en este momento donde alguno de los responsables del conflicto dirá una de las siguientes frases:

• "Es que no se podía hacer de otra manera. El diseño estaba mal." El momento de disparar la alarma era cuando no se podía codificar la funcionalidad. Ahora vemos que no fue válido hacerlo de otra manera, y que se ha malgastado el tiempo que debía haberse dedicado a corregir el diseño. Tiempo perdido que genera más tiempo perdido, ya que necesariamente hay que hacer una adaptación para poder seguir integrando.
• "Pero esta forma es mucho mejor". Puede ser. Pero ahora tenemos una porción del sistema que no encaja con las demás. Está mucho mejor que las demás, pero no encaja. Supongamos que tengo 10 módulos y uno está "mejor". ¿Hay que ajustar los otros nueve? ¿Cuándo? ¿Con qué tiempos y presupuesto?
• "El módulo funciona, yo terminé mi tarea a tiempo y correctamente". Esta es una variación de la conocida frase multiuso "En mi máquina funciona". Justamente estamos en la situación en la que vemos que el módulo no funciona en **este** sistema, y el hecho de que funcione en **otro** sistema (parecido a este) no es relevante.
• "Es que no entendí. Yo pensé que el diseño decía esto." Esta es la única respuesta válida, si es sincera. Y revela no una falta del programador, sino probablemente del equipo en su conjunto. ¿Por qué se mal interpretó? ¿Era confuso? ¿Cómo no nos dimos cuenta antes? ¿Faltaron puntos de control? ¿Faltó hablar más entre nosotros?