Hace un par de días me encontraba instalando bibliotecas de software para un proyecto. Al no tener conocimiento de los efectos colaterales o resultados de interacción entre varias bibiotecas (o «librerías» como les decimos los del gremio, por extensión a un barbarismo con el término «library«) debo instalar, probar una configuración, ver qué pasa y luego hacer lo propio con otra combinación.

Mientras lo hago, al ver la libertad de poder hacer lo que me venga en gana en mi ambiente de desarrollo no puedo evitar recordar lo opresivo y limitante de otras experiencias laborales en este aspecto. Yo creo que esto da el porqué tantos servicios y aplicaciones digitales en los que hoy en día basamos nuestras labores diarias resultan tan funestas.

El desarrollo de software se hace hoy en día considerando el entorno ideal en el que la operación, aplicaciones y servicios se desenvolverán: cuando todo funciona bien. En la práctica eso no es más que un caso especial de una realidad más complicada.

Considérese una aplicación (sea un programa o algo más elaborado como una suite o todo un sistema de información). Esta estará conformada de, al menos, un programa y varias líneas de código (que consumen datos y realizan operaciones sobre éstos). La complejidad de éste ira en aumento conforme a se agreguen más líneas de código, módulos y librerías de funciones (propias o de terceros), mas la complejidad de las operaciones (reglas  o procesos de negocios como les gustan llamarlas) y la cardinalidad de valores o símbolos que el conjunto de datos puede llegar a adoptar. En este punto debemos entender que un programa puede fallar por errores de programación (a lo que nos referiremos para denotar acciones equivocadas— como dividir entre cero, incompatibilidad de tipos, etcétera —), errores de lógica (mala o equivocada implementación algorítmica), pero también a «errores de datos» (que creo muchos considerarán que siguen siendo errores de programación, y estaré de acuerdo en general, pero quiero hacer incapié en que si bien el programa puede estar lógicamente bien con el ideal de datos que puede recibir, esto no garantiza que siempre sea así; ya he visto muchos casos de programas, aplicaciones y servicios que «se caen» porque les llega un dato inesperado del que se suponía «nunca debía haber llegado»).

A lo anterior debemos sumar el que el programa debe interactuar con un sistema operativo en el que hay políticas de seguridad, actualizaciones y la convivencia con otros programas. Si la aplicación resulta tener que adaptarse a un modelo de capas (cliente-servidor, tiers, distribuido), agregaremos no sólo una variable más sino un orden de magnitud de potenciales problemas y dependencias (networking, bases de datos, middleware, web servers, streaming o feeders, etc.). Súmese a esto modelos de programación en los que el tiempo ya no es el orden básico de estructuración de instrucciones (por ejemplo, un paradigma orientado a eventos presupone que la acción sobre un conjunto de componentes de software puede ser iniciado desde cualquier punto, no desde el inicio del código, como ocurre con las aplicaciones para navegadores de internet).

Así, puede uno darse cuenta de la enorme cantidad de variables involucradas. Considerar que que todo esto funcionará adecuadamente todo el tiempo, es la ilusión del mundo ideal al que me refería al inicio de esta entrada. Simplemente es un caso especial, una configuración de muchas de las que puede ser adoptadas por el sistema (el conformado por todos estos elementos y sus relaciones entre sí).

Cuando uno desarrolla una aplicación debe estar consciente de todo esto (y quizás más). Uno debe escribir código pensando en todos estos problemas potenciales y, si bien no resolverlos todos, evitar causar más daño cuando uno de ellos se presenta. Yo lo he hecho así. Quizás no sea el desarrollador más rápido, pues debe uno meter muchos elementos de control e «inteligencia» en un programa para que se defienda sólo  (cosa que a veces a molestado a más de uno de los jefes que me ha tocado tener) pero estoy contento con saber que mucho de lo que he producido es liberado y nos olvidamos de él por un buen tiempo, pues no suelen «tronar», ni a la primera ni frecuentemente.

Para lograr esto, uno debe poder proveer un entorno en el que se presenten estos problemas. Lo que implica provocar problemas, corromper datos y estructuras, e incluso destruirlo, obligando a reinstalarlo incluso en su totalidad (hoy hay muchas soluciones que hacen esto más fácil y rápido que serán tema de otra entrada).

Así hoy, mientras tengo la libertad de poder hacerlo, no puedo evitar recordar situaciones como  muchas que viví en Banamex, donde simplemente no podía hacer mucho de ello pues implicaba tener que pedir una larga cadena de firmas y autorizaciones para obtener passwords, instaladores, licencias (no comprarlas, sino tener el valor en mano para reinstalar), accesos privilegiados, explicar por qué debía reinstalar, etcétera. Cuando todo esto es tomado como si fueran elementos de seguridad nacional, es entendible que las aplicaciones mejor sean elaboradas para un caso ideal.

No es de extrañar que aplicaciones como la de banca móvil de BBVA (que aunque la presumen como «la mejor del  mundo») tenga tantos problemas y fallos. Les apuesto que mucho de su desarrollo está basado en el caso del mundo ideal.