Lo que aprendí del desarrollo de Software cuando construí mi casa.

El día en que finalmente los trabajadores se fueron de la obra y pude llamarla propiamente “casa”, noté con asombro que mi cuerpo y mi mente experimentaban el mismo cansancio que es familiar a los días posteriores a un deadline sacrificado y demandante. La satisfacción de la conclusión y la confirmación del esfuerzo.

Dicha coincidencia y las reiteradas conversaciones, de la mano de las dificultades que supimos sortear con Gustavo — el albañil/arquitecto que llevó a cabo la construcción — dieron lugar a esta reflexión que, humildemente, considero útil en mi cruzada desmitificadora de lo que se puede entender como el desarrollo de Software.

Lo primero es que el contexto es todo.
O casi todo.

Los pericias de una casa de campo que carece de acueducto y alcantarillado o red de gas doméstico, son abismalmente distintas a las de una obra que se abre paso en un barrio tradicional de una ciudad densamente poblada.

Como todo, aquello que en una circunstancia es una ventaja, en otra totalmente distinta, es una complicación. Es así que las condiciones provistas por el contexto no son inherentemente mejores ni peores que otras.

Según el caso y quién decida adelantar la obra, es posible establecer criterios subjetivos para preferir un contexto por encima de otro — criterios, una vez más, como todo, discutibles.

Hilando más profundo en lo que al desarrollo de software respecta, el contexto es sinónimo de acoplamiento. Y así como cada día se incrementa el número de servicios públicos y privados que integrar a las obras en ciudades altamente acopladas, no es casualidad que una de las tendencias en el desarrollo sea la implementación de arquitecturas orientadas a microservicios. Que sería el equivalente al cableado, acueducto, alumbrado y gasoducto de las metrópolis codificadas.

A diferencia de un lugar de retiro en el campo donde pasar el fin de semana y las fechas especiales, en la actualidad el Software aislado cual casa que adorna una prístina llanura verde, no sólo no existe, sino que ofrece una utilidad dudosa.

Sólo sé que nada sé.

Superada la complejidad que se deriva de las dependencias de la casa o el sistema como un todo que se abre paso en un ambiente especifico, se entra propiamente en materia, en el quid del asunto.

Los trabajos creativos, trátese de un poema, un dibujo, un plano o un algoritmo, deben lidiar con una cuota de incertidumbre, que se refleja justo antes de comenzar la tarea. A esta incertidumbre se le puede equiparar con el bloqueo del escritor cuando se encuentra con una hoja en blanco.

Esta incertidumbre inmovilizadora se convierte en un tema sensible especialmente cuando este producto de la creatividad tiene que alinearse con perspectivas económicas y encajar en una planeación previsible. Usualmente esta incertidumbre se deriva y proyecta en la estimación de la fecha de conclusión.

La asertividad de la estimación y sus catastróficas consecuencias en caso de equivocación, están directamente relacionada al grado de incertidumbre.

Lo cual resulta evidente, pero con frecuencia para llegar a esta conclusión se hace falta transitar las penas y glorias propias del proceso y justamente es entonces cuando se ha disipado la incertidumbre.

En la construcción y en el desarrollo de software, eliminar la incertidumbre a priori, al menos en los aspectos técnicos es el equivalente a iniciar el desarrollo.

Es una paradoja que ha dado lugar sin número de metodologías y que cada tanto se cobra una implementación ambiciosa o un modelo de negocio innovador. Se trata entonces de una versión más aterrizada de la analogía del gato de Schrödinger. O a caso más sofisticada de la del huevo y la gallina.

El efecto mariposa.

Finalmente, por más precisos que sean los conocimientos en construcción o en programación para ejecutar el proyecto, y aún cuando se tomen resguardos en recursos, resulta imposible prever cada contratiempo o inconveniente y el efecto que estos tengan sobre el resultado final. Más aún cuando el plan de ejecución definido está compuesto de tareas fuertemente encadenadas.

Es difícil interpretar con certeza el impacto que una decisión tomada para solventar un inesperado, por ejemplo, en el cimentado de una edificación, tendrá en el edificio como un todo. Una diferencia en la capacidad del acueducto planeado vs el real es tan drástico para la solución final como la incompatibilidad entre dos módulos centrales en una aplicación compleja.

Hay casos donde las diferencias entre lo ideal y lo real son nimias y el resultado es propiamente el esperado, así como existen casos donde un error en la planeación o interpretación de la situación hunden para siempre el proyecto.