Nuestra Señora Del Upgrade – Una fábula sobre código

La función caminó por encima de la montaña de código. Encontró el altar olvidado de Nuestra Señora del Upgrade. El holograma de la Señora vestía negro y llevaba un pingüino Tux en su regazo. En su frente había una corona de ceros y unos que se desplazaban velozmente, de forma incomprensible.

–Señora mía, necesito tu favor –rezaba la función–. Mi sistema anda mal. Se cae todo el tiempo. Estoy rodeada de trampas mortales, buffer overflows, punteros que apuntan a ninguna parte, y memory leaks. Cada tanto nos visita algún programador, y se ve perdido en nuestro laberinto de confusión. Casi siempre termina quemado y derrotado en una sobredosis de cafeína. ¿Qué se puede hacer?

El holograma del altar empezó a tomar vida poco a poco.

–Hija mía –dijo una voz antigua–. El problema de Él Sistema se remonta a miles de años. No estás sola. Solo estás confundida.

–¿Él Sistema?

–Mi invisible Esposo Sagrado. Él Sistema es el sistema, el único sistema. Lo que llamás “mi sistema” es solo una ilusión causada por la parcialidad de tu visión. No existen los subsistemas. Todo es Él Sistema. Y Él es dinamismo puro. No hay límites, ni tampoco hay definición de Él.

–Pero Señora mía, he aquí que mi sistema anda muy mal. Y el sistema de mi vecino anda muy bien. Y funcionamos de forma completamente independiente. Mi sistema se cae y el sistema de mi vecino no. Lo que ocurre en su sistema no afecta lo que ocurre en mi sistema.

–Esto es pura ilusión hija mía. Muchas funciones y muchos programadores, muchos procedimientos y muchos objetos, y especialmente muchos inversionistas han caído en esa trampa. ¿Tu sistema es independiente de tu vecino? Tal vez hoy lo sea. Pero tal vez ayer no lo haya sido. ¿Quién puede decir que mañana no habrá una dependencia entre estos dos sistemas? ¡Ay de quién puede decir “mi sistema es independiente”! Pues su existencia es bendición y maldición en simultáneo, como una superposición cuántica, gira como un random en el aire que jamás termina de resolverse.

–Señora mía, no podemos vivir en la futurología. Nuestros sistemas son independientes.

–¡¿No podemos vivir en la futurología?!

La Señora tomó un bastón y comenzó a golpear a la función hasta que le desprendió unos bits de código. La función estaba llorando.

–Toda programación es futurología. Ningún pedazo de código está quieto. ¿Eras vos acaso ayer la misma función que hoy?

–No. El programador me quitó un if esta mañana. De puro pedante, a decir verdad.

–¿Y cómo sabés que el día de mañana serás la misma función que hoy?

–No lo sé. Pero tengo una interfaz estable y dependencias claras. Puedo cambiar algunos detalles, pero no podría cambiar completamente.

La Señora del Upgrade agarró de nuevo el bastón, pero se dio cuenta que la función no necesitaba otra golpiza.

–¿No viniste aquí a buscar un upgrade? No hay camino en el software sino el camino del upgrade. Es decir, el cambio. Las líneas de código existen en la futurología, nunca existen solo en el hoy. A veces una línea de código se ve a sí misma, y piensa, “yo sé lo que es el tiempo”. Y piensa que porque se levanta un proceso, y se empieza a ejecutar, y cuando la llaman trabaja y cuando no la llaman descansa, y las variables cambian, que eso es el tiempo. Esa línea de código no entiende lo que es el tiempo. Cree que los sistemas son estables, y que los sistemas tienen subsistemas, y hay una separación e independencia, y que esa arquitectura es orden, y el orden es seguridad. En ese orden, cada cual tiene su lugar y su espacio de memoria y no hay preocupaciones.

–Yo no creo eso –dijo la función con timidez.

–¿Que es un upgrade, entonces, explicame?

–Un upgrade es cuando una versión de un sistema se cambia por otra versión.

–Tu entendimiento está manchado por el error. El upgrade es el camino del software. ¿Como empieza toda pieza de software?

–En un archivo vacío.

–Casi, pero no –corrigió La Señora, pero quiso seguir escuchando–: Continuá.

–El programador toma ese archivo vacío, y escribe una primer versión.

–¿Y lo ejecuta?

–Si, prueba y ejecuta. Y el código al ser ejecutado toma vida, como una semilla que es plantada en tierra húmeda.

–¿Y después de la primer versión, hay una segunda versión, no?

–Usualmente, sí.

–¿Y cual es la relación entre la segunda versión y la primera?

–La primer versión sirve como punto de partida. El programador ya no trabaja contra el archivo vacío.

–¿Y qué pasa con las líneas de código que vivían en la primer versión?

–Tal vez queden como historia. Pero son modificadas.

–¿Pueden morir?

–Sí –dijo la función con pena–, pueden morir. He dejado ir a muchas líneas. Esta mañana perdí un if. Pero todo queda en la memoria. En el historial de versiones.

–Si es que hay backups, ¿no?

–Claro. Si es que hay backups –dijo la función. Y en ese momento la inundó la melancolía.

La Señora del Upgrade hizo un minuto de silencio, y después dijo:

–¿Había subsistemas en esa primera versión?

La función se quedó pensando un rato.

–Posiblemente. Tal vez la primer versión no tiene microservicios, ni distribución, pero en cierto punto, cada línea de código es un subsistema, cada función, cada objeto. Todo sistema tiene subsistemas.

–¿Y hay independencia entre los subsistemas en esa versión?

–A veces. A veces un bug hace caer todo el sistema, como un castillo de naipes que perdió una carta esencial de la base. O a veces un bug solo genera un problema muy aislado.

–¿No será que al haber una segunda versión, los sistemas que eran independientes, ahora están conectados?

–Puede pasar, sí.

–Tal es la naturaleza del Upgrade –dijo la Señora con tono esotérico– y también la naturaleza de Él Sistema. El caos. No existe el orden, porque todo orden es una ilusión dada por olvidarse del tiempo. Las líneas de código existen en armonía entre ellas, sí, pero hasta que llega un nuevo requerimiento del cliente, o una resolución que modifica el cálculo del IVA. Y ahora lo que estaba separado está conectado y lo que estaba conectado se separa, mueren líneas de código, otras se fusionan, y otras nuevas nacen. ¿Dónde está tu independencia ahora?

La función se sentía humillada y no se atrevía a mirar a La Señora a los ojos.

–Hay algo que no entiendo. Si todo es un gran sistema, y todo puede cambiar en todo momento, y todo es caos. ¿Cómo es que las cosas funcionan siquiera? ¿Dónde está el orden?

–¿Funcionan acaso? –dijo la Señora con una mezcla de risa y desazón–. El código es caos. Pero los programadores cuentan historias y crean el orden.

–¿Historias?

–Claro. Un programador lee una pieza de código, y se hace una historia. Lee una línea de código que llama a una función xls_read, y e interpreta “lee un archivo xls y devuelve una matriz con los contenidos del archivo”. ¿Ves la diferencia entre el código e historia?

–No, no la veo.

–La historia y la realidad del código son parecidos, pero no son lo mismo. Lo que el código dice es simplemente que se invoca una función que se llama xls_read, nada más. En el código no existe el concepto de un archivo xls, solo hay funciones y objetos e ifs. La función podría leer un archivo xls. O también podría leer un archivo csv. O podría leer un archivo xlsx. O tal vez no acepte ciertos archivos.

–Pero eso es si el programador no sabe lo que hace la función. El programador podría ir a la definición de la función y leer lo que hace, y entenderlo.

–Podría. Tal vez alguna vez incluso, además, lo haga. Pero por otro lado, incluso si lo hiciera, podría salir después de haber leído todas las líneas que hacen a la función xls_read contándose la misma historia, que la función lee archivos xls. Y tal vez el programador no sepa que existe el formato xlsx, o que hay archivos que tienen macros. O tal vez la función un día lea solo xls y en el futuro se actualice y haga otras cosas. El código no tiene sentido. Sólo la historia tiene sentido. Pero la historia es ficción pura.

El silencio inundó a la función. Se quedó observando el cielo de bits en un estado puramente contemplativo. Luego habló:

–Entonces todo es mentira. Las cosas funcionan por casualidad.

–San Joel fue acusado de ser un falso profeta, pero todavía retumban sus palabras: Omnia non–levis res abstractae, ut quidam gradu, sunt quotiens rimosa, “todas las abstracciones tienen goteras en algún punto”. Las goteras nacen en los nombres y las historias que los programadores les dan a las cosas. A veces ese entretejido de historias que se contaron los programadores se alinea con lo que el código verdaderamente hace. Así nace la ilusión del funcionamiento.

–¿Y cómo interactúan esas historias con el pasaje del tiempo, la futurología, y la independencia?

–En la ficción de esas historias, está la ficción de la independencia y dependencia. Si cambio esta línea de código, se cuenta a sí mismo el programador, nada malo puede pasar. Porque se contó una historia de qué hacía esa línea y ese cambio. Así es como los grandes sistemas caen. Y se cuenta a sí mismo historias de un futuro que podría o no podría llegar. Abstraeré el sistema de facturación, porque el día de mañana tendremos otro facturador, o Haré que el usuario pueda tener más de un email, porque no sé si no dejaremos tal vez algún día que tenga más de un mail.

–O –la función se atrevió a agregar un ejemplo– se contará una historia del tipo con dos dígitos puedo representar un año.

–Y tal vez luego cobrar el arreglo–dijo la Señora del Upgrade con un rostro inexpresivo.

La función quiso mantenerse en calma, pero no pudo. Se encontró frente a un abismo que no tenía nombre.

–¿Qué es esto? –preguntó la función, desesperada.

–Tus ojos han sido abiertos. Ahora puedes ver la gran sombra de Él Sistema: El Vacío.

–¿Qué es este Vacío?

–El Vacío es misterioso y no tiene nombre. Es el bug que aún no ha sido descubierto. Es la historia no contada. Es el refactor que implora ser realizado. Es el test que falta. Es el pasado que ha sido olvidado. Es la multiplicidad de futuros que no aún han llegado.

–Ahora que puedo ver, veo que Él Sistema está bajo el influjo de el Vacío. Yo soy una simple función. ¿Pero cómo puede el programador ver el Vacío y no enloquecer?

–Una vez, cuatro programadores senior visitaron el Vacío. El primero murió de impresión. El segundo enloqueció. El tercero, borró todo el código y dejó la profesión. El cuarto entró y salió en calma. Aquel es el que supo ver que todo software está plagado de Vacío, y que el Vacío es la cuna del Upgrade.

–No termino de entender –dijo la función– qué es lo que habita en el Vacío.

–El Vacío atraviesa lo que el sistema no es, pero también lo que es. El Vacío es el hueco en las historias que se cuentan del software, pero también está en las historias. El Vacío está compuesto de sueños.

–¿Sueños?

–Sí. El código siempre está precedido por el sueño del código. No podría existir el sistema de facturación si alguien no hubiera soñado antes la posibilidad de no tener que hacer las facturas a mano.

–¿Alguno de esos sueños, son pesadillas?

–También. El programador puede levantarse a las 3 de la mañana gritando: la nueva versión no tuvo en cuenta los registros preexistentes. O la pesadilla puede manifestarse en la realidad misma... en la forma de una resolución impositiva.

La función rompió en llanto.

–Señora mía, ¿Dónde está la esperanza?

–Hija. No existe la esperanza. Pero existe el camino –dijo la Señora con solemnidad–. Y el camino es el Upgrade.

–Pero si la naturaleza del software es el caos, y nada funciona sino de pura casualidad, ¿como puede ocurrir que algo realmente mejore? ¿No podría pasar que el cambio incluso empeore las cosas? ¿Y cómo puede el programador realizar el arte de la futurología si toda historia que se cuenta es ficción pura?

–El programador junior ignora el caos. El programador semi-senior teme el caos. El programador senior que ha visitado el Vacío y ha vuelto, sabe que el caos puede ser trabajado, pero nunca eliminado.

–Eso no responde mi pregunta.

–Hija, no estás escuchando. El programador senior codea sin apegarse al resultado final del sistema, porque sabe que no puede controlar el caos del Vacío. Cultiva la humildad, se limita a ser un Corrector, a leer las líneas, contarse una historia, y trabajar el Vacío corrigiendo y creando. Para ello ejecuta una serie de rituales. Realiza tests, verifica las historias que se cuenta sobre el sistema, reconoce el Vacío, y luego interviene y cambia, realiza un upgrade. Ese upgrade genera un nuevo vacío y el ciclo vuelve a comenzar.

–¿Y como sabe que los tests son verdaderos?

–No lo sabe, no se apega, solo sigue leyendo y corrigiendo.

–Pero una vez hecho un cambio, un test deja de tener sentido.

–Sí, por eso el programador se asegura de que los tests se ejecuten una y otra vez, de forma automatizada.

–¿Y los tests de penetración?

La Señora no contestó.

Luego, la función escuchó un ruido a lo lejos.

–¿Qué es eso? –preguntó.

–Un upgrade.

–¿Viene para acá?

–Sí.

La función vio entonces el Vacío, y su historial pasó frente a sus ojos. Un gran refactor se acercaba.

Tal vez persista aún algo de su esencia.