Proyectos y entropía de software

"the basic law of life to be ever more highly structured and to struggle against entropy" — Vaclav Havel

Jay espera por su amiga en un café. Es jueves y después del “happy hour” han quedado en juntarse con más frecuencia, pues Jay espera que su amiga Bee le ayude a mejorar el desempeño de su equipo, aprendiendo de su experiencia en una empresa con una cultura más “ágil y moderna”.

Cuando Bee llega luce cansada. Le cuenta a su amiga que tuvo que responder una alerta a las 4 am, tal como muestra la app de PagerDuty, con seis alarmas de la plataforma a esa hora de la madrugada. “Esta es quizás de las cosas que menos me gusta de mi trabajo”, le cuenta, los turnos “on-call”, pero es parte de la cultura de “excelencia operacional” que promueve mi empresa. “Si tú lo pasas a producción, tú te encargas de asegurarte que funcione correctamente”. Jay toma nota, y acuerdan hablar de eso más adelante.

Por ahora se centran en las necesidades más urgentes de Jay.

“Las iniciativas se atrasan cada vez más”, “la cantidad de errores no nos deja avanzar”, “no tenemos la confianza de nuestros clientes internos”, y “los product owners no se involucran y no entregan los requerimientos a tiempo”. Las quejas típicas que oirías de un jefe de proyecto.

— ¿Cómo lo hacen ustedes, Bee? — le pregunta con algo de desesperación. 

Bee sonríe. 

— No creas que estamos libres de esos problemas.

Lo mismo que le pasa a su amiga lo ha observado Bee también. Ambas recuerdan una clase de Ingeniería de software cuando el profesor les hablo sobre tres características malditas del desarrollo de software:

1. Nunca tendremos los requisitos completos antes de empezar

2. Los requisitos cambian con el tiempo

3. Siempre queremos hacer más de lo que el tiempo y el dinero asignado permite

Después de reír, Bee pregunta a su amiga si conoce el trabajo de Lehman sobre entropía de software. Jay le responde que no, que no ha oído hablar nunca de eso. 

— No me extraña - acota Bee — verás, este señor, en 1980 publicó un artículo donde habla de los programas como modelos de la realidad. 

— Obvio — responde Jay. 

— Sí, pero la clave es que Lehman profundiza más allá. Verás hasta antes de su trabajo, todo el mundo clasificaba los programas en grandes y pequeños, y con eso despachaban el problema de la complejidad de abordar estos proyectos.

Entonces Bee cuenta cómo Lehman se dio cuenta de que estos modelos son abstracciones de porciones del mundo, o más bien de un universo del discurso que tenemos sobre el mundo. Para entender la verdadera dificultad, propone clasificar los sistemas, o programas como Lehman los llama, en tres: S, P y E.

Meir Manny Lehman

Los s-programs corresponden al software cuya funcionalidad se define formalmente por una especificación S (specification). Es el programa que surge de la adherencia a un método formal, o proceso de desarrollo de software, que contempla la elaboración de estas especificaciones. La especificación es muy precisa en este caso: “dadas estas entradas esperamos estas salidas”.

Jay recuerda que su tío le contó de un sistema que desarrolló, que recibe archivos de entradas, lee una configuración que mapea el formato del archivo de entrada en campos de una tabla estándar, y traduce uno en otro, para terminar insertando los registros en una base de datos. Ese programa quedó operando y casi dos décadas después llamaron a su tío porque debían migrar el programa de una plataforma con sistema operativo de 32 bits a uno de 64 bits. El tío se gastó unas pocas horas en recompilar el programa, y cobró mucho dinero, pero el programa sigue ahí operando hasta hoy, quizás es un sistema que está por cumplir la misma edad de ellas.

S-Programs de acuerdo a la visión original de Lehman

— Ese es un ejemplo de que todo programa o sistema está siempre expuesto a la obsolescencia tecnológica, pero de todas maneras, lo que mencionas es un buen ejemplo de lo que Lehman llamaría un s-program.

— Ojalá todos los sistemas fueran de ese tipo — suspira Jay.

La siguiente clase de programas, le cuenta Bee, corresponde a aquellos  en que la especificación no es precisa. Esta especificación es un modelo de una abstracción de una situación del mundo real que contiene incertezas, incógnitas, criterios arbitrarios, variaciones, etc. En cierto punto refleja la visión personal del analista que la redacta. En este caso, tanto la formulación del problema como su solución son una aproximación a la realidad del mundo. A estos tipos de programas Lehman los llamó P-programs (“real world problem solutions”).

En este caso existe un ciclo de comparaciones de esta solución con el entorno real. En los s-program la comparación es contra la especificación, en este otro caso la comparación es contra la realidad, verificamos si los valores obtenidos por el programa son válidos en el contexto del mundo real. Las diferencias entre la data derivada de la observación y la derivada de la computación causan cambios en nuestra visión del mundo, en la percepción del problema, su formulación, el modelo, la especificación o la implementación del programa. Cualquiera que sea la causa de la diferencia provoca que el código y eventualmente su documentación deban cambiar. Este efecto no puede ser eliminado declarando que el problema es un nuevo problema (como hacemos con los s-programs), lo que ha cambiado es la percepción que tenemos del mismo problema.

— Lo relevante — es que las imperfecciones que observamos de nuestro modelo se superan con el tiempo. Pero el mundo también cambia, así que los p-programs van a sufrir cambios permanentes, o se volverán cada vez menos efectivos, tanto en resultados y en costos — comenta Bee.

—  Y ahí surgen nuevos proyectos para reemplazarlos.

— Exacto, de ahí surge la ley de la entropía de software de Lehman.

“Un programa que es usado sufrirá cambios continuos o se volverá progresivamente menos útil.”

La tercera clase de programas son inherentemente más expuestos al cambio, acota Bee. Son los que Lehman llama E-programs. 

Te voy a mencionar el caso del producto en que trabajo, le dice Bee.

Le explica que en su caso ellos tratan de resolver un problema logístico. Donde distintos operadores en terreno que reciben instrucciones a través de la aplicación (en sus móviles), en que además ellos proveen de nueva información al sistema. En este caso, la instalación del programa junto con todo el sistema asociado (dispositivos, redes, etc.) cambia la misma naturaleza del problema a ser resuelto. El programa pasa a ser parte del mundo que modela. Aunque no consideremos la evaluación de los resultados de ejecución del programa en su ambiente operacional, este tiene un ciclo de retro alimentación intrínseco.

Ejemplos de e-programs abundan, desde los sistemas operativos hasta sistemas de control de tráfico aéreo. En todos estos casos el comportamiento de la aplicación, las demandas de los usuarios y el soporte requerido dependerán de las características del programa. Esto llevará a que los usuarios modifiquen su comportamiento para adaptarse al sistema con el fin de minimizar el esfuerzo y maximizar su efectividad. Es inevitable que esto lleve a presiones por cambios. Adicionalmente, las presiones exógenas también causan cambios en el ambiente donde la aplicación opera. Nuevo hardware, avances tecnológicos e incluso la evolución de la sociedad introducen también cambios. Más aún, la naturaleza y la tasa de esta evolución estará fuertemente influenciada por las características del programa, en la medida que se liberan nuevas versiones del mismo. A diferencia de otros sistemas, acá la presión por el cambio es permanente e interna, es intrínseca a estos sistemas.

— ¿Todo esto es muy interesante, pero de que me sirve? — pregunta Jay

— Ah, primero para entender que lo que nos enseñaron tiene una razón, y no es un simple consuelo. Segundo puedes clasificar mejor el riesgo de las iniciativas, y de ese modo sabrás que si se trata de un s-system el riesgo está acotado, y si se trata de un e-system, lo más seguro es adoptar un enfoque de producto que uno de proyectos. Y por último, porque cuando empezamos a hacer distinciones adecuadas nos podemos aproximar a nuestros problemas de una forma más productiva.

Jay se queda pensando sobre esto. Paga el café y quedan en que la próxima oportunidad van a hablar sobre formas más concretas de afrontar esta complejidad.