Mostrando las entradas con la etiqueta historias. Mostrar todas las entradas
Mostrando las entradas con la etiqueta historias. Mostrar todas las entradas

14/03/2022

Historias de las trincheras. Una aplicación exitosa

Armas al Hombro. Charles Chaplin

Permítanme antes de ir al hueso de nuestro tema una pequeña historia

Dígame si le parece familiar el siguiente relato ficticio. Se empieza a trabajar en un proyecto de software. Siguiendo las buenas prácticas de la época se intenta separar las capas de la aplicación en modelos, vistas y controladores. Se decide usar la versión más moderna del lenguaje de moda, y la última versión disponible de su framework más reconocido el cual viene integrado con su propio ORM. Se decide además usar el motor de base de datos XSQL como capa de persistencia de datos. La aplicación es un éxito. Cada vez más clientes contratan sus servicios y el número de estos comienza a crecer exponencialmente, hasta contarse algunos miles de usuarios; y después de algunos años hasta empiezan a haber planes de internacionalización.

En ese momento, las peticiones de soporte empiezan a crecer, y un buen número de estas trata sobre la velocidad y tiempos de respuesta de la aplicación. La primera idea es actualizar los componentes del sistema a versiones recientes, pero ¡Oh, sorpresa! el componente que se encarga de manejar xml tiene como dependencia un paquete descontinuado, y el ORM integrado depende del paquete que maneja xml. Como imaginará, si no actualiza el ORM no puede actualizar el framework que lo integra, y las nuevas versiones del lenguage soportan el framework desde la versión 3, cuando su aplicación se basa en la versión 2

La actualización de las dependencias de software no es posible.

Surge entonces la idea de montar la aplicación en máquinas más poderosas, si no podemos actualizar el software, actualicemos el hardware. Entonces contratamos máquinas en el proveedor de servicios cloud mas conveniente. También se empieza a escuchar sobre un nuevo trending en la industria del software, los microservicios. Si descomponemos la aplicación en un conjunto de pequeñas utilidades que realizan un solo trabajo, lo realizan bien, y gatillamos su inicio con llamadas a api, mejoraran los tiempos de respuesta por la simple razón de que puedo levantar muchas máquinas en nuestro proveedor cloud con los microservicios mas demandados.

Todo va viento en popa, los tiempos de respuesta mejoran ostensiblemente y la internacionalización es un hecho. Sin embargo, la moneda del nuevo país donde tenemos clientes posee una submoneda; centavos, centimos, peniques o como se llame. Es decir, los montos que la aplicación debe manejar son números con decimales. La moneda del país original no contaba con algo parecido y todos los cálculos monetarios eran redondeados a números sin decimales.

Rápidamente se desarrolla una corrección, que consiste en cambiar el redondeo desde no conservar decimales a mantener un número arbitrario de estos. Esta corrección hace los cálculos monetarios usando el tipo de datos de números de coma flotante, los cuales no pueden representar con exactitud números decimales debido a la impĺementación de su aritmética, por lo que cuando se ven involucradas cantidades muy grandes, aparecen diferencias inaceptables en los monto calculados.

Usar un tipo de dato especial, del tipo BigDecimal o Currency esta fuera de discusión porque prácticamente significa reescribir la aplicación.

Por otro lado, como seguimos vendiendo los servicios del sistema, los clientes siguen multiplicándose, volviendo a aumentar los tiempos de respuesta. En esos momentos, un miembro del equipo propone migrar el manejo de la capa de persistencia de datos a ZSQL o Y-NOSQL cuyos benchmarks demuestran una velocidad con la que el viejo y querido XSQL solo puede soñar. Pero, tras hacer los experimentos necesarios, vemos con horror que el ORM del framework no soporta ninguna de estas nuevas alternativas.

A estas alturas, uno como programador no puede hacer mucho más que resistir en las trincheras. Después de todo hay que poner pan en la mesa y se nos paga por escribir código, bugfixes y nuevas features, no por ventilar nuestras preocupaciones. Tampoco pueden hacer mucho líderes de equipo ni product owners, pues deben responder ante críterios comerciales. No, en esta situación no hay nada mas que hacer que resistir en el frente sacando correcciones, con la esperanza de alcanzar a ver el armisticio que marque el cese al fuego. Y a veces cae fuego pesado desde todos los frentes.

12/03/2022

De historias, errores y humildad

Hace muchos años, a finales de los noventas, trabajaba como guardia de seguridad cuidando el edificio de un centro de formación técnica que había quebrado. Este se encontraba en Moneda, entre Amunategui y San Martín. En su tejado pasé la noche del año nuevo del 1999 al 2000, mirando los fuegos artificiales de la Torre Entel comiéndome un pollo asado que me habían regalado unos transeúntes que iban a ver los fuegos.

En sus instalaciones se encontraban restos de materiales para la formación de técnicos en odontología, como modelos de maxilares con dientes de goma, maniquíes, y hasta un modelo a tamaño real de un cerebro hecho no se de que materiales, pero que parecía muy real.

Inevitablemente cometeremos errores, por lo que debemos estar abiertos y preparados a que aparezcan. Porqué la programación es una actividad humana, realizada por humanos, y no somos infalibles.

Sin embargo, lo que mas llamaba mi atención era la biblioteca del extinto centro. Un salón enorme repleto de libros tirados por el suelo y amontonados en viejos estantes conteniendo la sabiduría de épocas perdidas.

Era una delicia pasar las noches explorándola buscando que leer hasta encontrar un libro que llamase mi atención y tirarme cuan largo era en un viejo sillón después de poner un casete de Iron Maiden en una radio igual de vieja.

Fue en una de esas bonitas sesiones que encontré un libro, el cual en ese momento me puse a leer de puro intruso. El título era curioso; The psychology of computer programming, de Gerald Weinberg ¿Como se va a aplicar psicología a las computadoras? fue la primera idea que se me ocurrió cuando empecé a ojearlo. Después de unas paginas ya entendía que donde se hablaba de psicología, se refería a las personas que programaban, es decir, el autor veía la programación como una actividad humana y social, intentando entender como las personas crean software y se reunen para hacerlo, dentro de una organización; un ambiente donde se desempeñan.

Uno de sus capítulos trataba sobre aceptar los errores entendiendo que estos no significan un menoscabo a la persona del programador; pues es muy distinto decir encontré errores en mi código, que decir encontré errores en el código que escribí. Lo que trae a colación el concepto de la propiedad del código. Los programadores no son dueños del código que escriben en el mismo sentido que los pintores son dueños de la obra que pintan, aunque la pinten para otros. Ejemplificando, Leonardo siempre estará asociado al cuadro de La Gioconda, pero los programadores que participan en un equipo escribiendo código para un proyecto no tienen propiedad sobre este y lo mas seguro es que nadie los recordará cuando se hayan ido del equipo y hayan pasado algunos años.

Ahora, muchos años después de esos eventos, y siendo yo mismo después de muchas vueltas de la vida un programador que comete muchos errores, recordar esa lectura me hace pensar en los problemas que enfrentaban los programadores del pasado, y en como estos problemas no han cambiado tanto aunque hayan pasado hartos años desde que se publicara el libro (1971) Es curioso como aunque en este tiempo han aparecido cientos de lenguajes, las máquinas han aumentado exponencialmente su potencia, y se hayan descubierto nuevos e interesantes patrones, los problemas que enfrentan las personas al programar siguen siendo, citando al autor:

  • Instrospección sin validación
  • Observaciones sobre una base muy estrecha
  • Observar las variables equivocadas, o fallar en detactar las correctas
  • Interferir con el fenomeno observado
  • Generar muchos datos y poca información
  • No fijarse en efectos grupales y comportamientros de grupo
  • Medir solo lo simple de medir
  • Transferir resultados a situaciones inaplicables

¿Le suenan conocidas algunas de estas proposiciones? Desde que trabajo como programador las veo una y otra vez, cayendo en ellas. Me hacen sentir una cierta hermandad con el viejo investigador que las propusiera.

Después de meditar, la conclusión a la que llego trata sobre la humildad que deberíamos adoptar quienes escribimos código. Inevitablemente cometeremos errores, por lo que debemos estar abiertos y preparados a que aparezcan. Porqué la programación es una actividad humana, realizada por humanos, y no somos infalibles.

Dejo el enlace a Google books y a amazon de The Psychology of Computer Programming para quien pudiera interesarse.