Del desarrollo de software como sistema de comunicación y la importancia de poder leer y escribir.

A veces me pongo extremista y veo al desarrollo de software solamente como un sistema de comunicación. Si lo vemos como una caja negra, se trata de de transmitir y traducir los requerimientos en una serie de instrucciones que un hardware pueda ejecutar, llevando a cabo la tarea que estos requerimientos representan. Por lo menos idealmente.

Si abrimos esa caja negra, encontraremos varios "puntos de retransmisión y traducción", que más o menos se corresponden con las etapas de relevamiento, análisis, diseño y codificación. Cada etapa nos acerca más desde el lenguaje del emisor (el cliente) al lenguaje del receptor (ese equipo de hardware).

En resumen, los requerimientos son el mensaje, el cliente es el emisor y el hardware que finalmente debe ejecutar la secuencia de instrucciones acorde es el receptor. En el camino tenemos varios retransmisores, algunos humanos y otros no: analistas de negocio, analistas funcionales, programadores, entornos de desarrollo, compiladores, personal de soporte al cliente (al instalar), sistemas instaladores. El mensaje se transmite a través de varias formas y a través de varios medios: oralmente, por escrito, electrónicamente.

Bajo esta óptica, somos retransmisores al tiempo que traductores.

Como en todo sistema de comunicación, hay ruido de fondo y ruido generado por el propio sistema. Ambos tipos de ruido deforman inevitablemente el mensaje. La comunicación perfecta no existe, por tanto tampoco existe el software perfecto.

Siguiendo por este camino, en el que suelo entretenerme inventando y perfeccionando analogías, llego usualmente a la siguiente conclusión (bombos y platillos):

La calidad del software depende de es la fidelidad con la que el equipo transmite un mensaje, por ello todos los participantes de un equipo de desarrollo de software deben ser excelentes transmisores de información.

De nada sirve ser un experto programador, analista o visionario del negocio si no se puede transmitir fielmente esa información a través del proceso de desarrollo.

Transmitir implica básicamente dos tareas: recibir y enviar. Incluso un programador independiente que trabaja absolutamente solo debe ser un experto escuchando o leyendo al cliente (recibiendo) y programando (enviando).

Recibir es usualmente escuchar, leer. Transmitir es usualmente hablar, escribir.

El problema de escuchar y hablar es que, como se dice coloquialmente, a las palabras (y muchas veces a las personas que las pronuncian) se las lleva el viento.

¡Cuidado! Ahí vienen los pseudo-ágiles: que el exceso de documentación, que la comunicación informal, que los cambios continuos y un largo etcétera.

¿Cuál es la diferencia entre pseudo-agilidad y verdadera agilidad?

En el desarrollo pseudo-ágil no se preserva nada. Llegamos al punto de encuentro con el cliente y estamos solos. ¿Qué pasó? No tenemos idea.

En el desarrollo ágil se preserva solamente lo indispensable: el mensaje, los requerimientos. Es absolutamente minimalista: hay que preservar sólo el mensaje, pero hay que hacerlo como si fuera la vida misma, y verificar continuamente que no haya sido malinterpretado por nadie. Como recalqué muchas veces: tal es así que en XP las historias del usuario las escribe el mismo usuario, y éste es parte del equipo. Creo que solamente por una cuestión legal las cadenas para retenerlo cerca del equipo (que seguramente figuraban en los primeros bocetos) fueron finalmente suprimidas.

Aclarado que tenemos que preservar al menos el mensaje original, los requerimientos, el tema es cómo.

Me agarra el viejazo cuando me vuelvo tradicionalista, pero todavía nadie me convence de lo contrario: el texto es el rey. Es la herramienta más sencilla para el conjunto de actividades que se realizan alrededor de los requerimientos: recibirlos, discutirlos, modificarlos, transmitirlos, catalogarlos, archivarlos, buscarlos.

Pensemos en otros soportes posibles. Omito los puntos "catalogar" y "archivar" ya que con las herramientas disponibles serán sencillos para cualquier soporte.

Los gráficos son más difíciles de producir y modificar, aunque usualmente mejores para discutir y transmitir. La búsqueda no es sencilla, justamente porque contienen poco texto.

En cuanto a imagen y sonido, grabar la descripción de los requerimientos parece una buena idea, pero no me parece un soporte fácil para recibir o discutir, mucho menos de modificar. No me imagino en una reunión diciendo "poné de vuelta esa parte... no... un poco antes... ahí, ¿no debería decir...?" La transmisión es más complicada y la búsqueda sólo puede realizarse bajando el contenido a texto.

Recordemos que hablamos de requerimientos que cambiarán continuamente. A mayor complejidad mayor resistencia al cambio. Y cambio en los requerimientos es moneda corriente.

Así que si me preguntan a mí, texto.

Resumen: habilidades a valorar en un integrante de un equipo de desarrollo (¿o mejor dicho, de un equipo, a secas?): leer y escribir (porque si no a las palabras -o al integrante- se las lleva el viento). ¿Alguna vez los evaluaron en eso en una entrevista de trabajo?

BTW: Menudo título, ya sé, pero estoy cansado de aparecer en cualquier lado por hacer bromitas con los títulos de los post. No lo hagan.