La historia de la consultoría de sólo código abierto.
¡Hola!, solo quería que sepas que "El Camino de Java, Volumen 2" sigue avanzando y recién he publicado más lecciones acerca de Spring. Ahora que estaba viendo los ejemplos y compilando el código me di cuenta de una situación que me trajo recuerdos, y es que si después de compilar tu proyecto con Spring tienes la curiosidad de ver qué fue lo que se generó, encontrarás que en el directorio lib existe una cantidad enorme de librerías incluidas, sin irme tan lejos, uno de los ejemplos que estoy viendo se compone de 20KB de HTML, 20KB de código, y ¡22MB de librerías! jajaja, eso me recordó a la consultoría que usaba solo código abierto y que en algún momento contratamos, te voy a contar la historia:
Bueno, pues el caso es que esta compañía quería implementar algún estándar para desarrollar, y después de mucho pensarlo llegaron a esta solución: Utilizar únicamente código libre. La lógica de esta decisión era que si el día de mañana tenían que contratar a un nuevo programador, es más fácil encontrar a alguien que conozca las librerías públicas, y con esto se evitarían la molestia (y el costo) de tener que entrenar a los nuevos elementos. Segundo, porque al ser un código abierto, se espera que no tenga errores porque estamos hablando de software que utilizan millones de personas, y si llega a aparecer un error, pues entre esos millones de personas habrá alguien que lo corrija en minutos, ¿no es excelente?, soporte técnico gratis, documentación gratis y una fuerza de trabajo infinita. Bueno pues con esta idea comenzaron entonces a desarrollar, ¿Que necesitamos crear HTML? pues bajemos una herramienta que genere HTML, ¿Que necesitamos validar fechas? pues bajemos esa herramienta para el manejo de fechas. Y así estuvo esta compañía, desarrollando su primer software, hasta que llegó el gran día, cuando se iba a instalar en los servidores para comenzar el periodo de pruebas. El equipo de trabajo muy orgulloso de su metodología de desarrollo, y entonces: ¡Oh sorpresa!. Resulta que el número de librerías que estaban incluyendo en el proyecto era tan grande, ¡Que no cabía en la memoria de la JVM!, qué risa me dio cuando me enteré, pero la primera lección es: Si vas a desarrollar para un servidor externo, al menos tómate la molestia de investigar las características de ese servidor, es cierto que Java está hecho para funcionar en cualquier lado, pero no porque funciona en la memoria de tu computadora significa que va a funcionar en cualquier tamaño de memoria.
Entonces se pusieron a revisar la aplicación como un todo, porque otro problema que salió a la luz, es que nadie se preocupaba por el trabajo de los demás, cada quien era libre de meterle al proyecto las librerías que necesitara, y obviamente al revisar el proyecto como un todo salieron cosas como que se usaban librerías de código abierto para cualquier tontería, por ejemplo estaban usando un Jar que ocupaba varios megabytes, solamente para convertir una cadena en una fecha y viceversa. Después de varias semanas de revisar el proyecto, éste seguía sin funcionar en el servidor, y cuando lo hacía, era lento de concurso, y entonces el líder de proyecto dio su informe: La aplicación no funciona porque los servidores tienen muy poca memoria, así que la solución es instalar más memoria. Pero resulta que hacer esto era demasiado caro, no es como comprarle más memoria a una PC, resulta que por muchos factores técnicos, como el hecho de que el servidor está distribuido en muchos servidores físicos, el costo de la memoria especial que usaban esos servidores y las altas tarifas técnicas, hacía que aumentarle la memoria al servidor costaría como 16,000 dólares (por 1GB de RAM), los cuales el director de IT no estaba dispuesto a pagar de su presupuesto.
Me gustaría decirte que la solución final fue optimizar el código para que lograra funcionar en un servidor con poca memoria, yo creo que eso se hubiera logrado simplemente haciendo que la JVM de cada programador fuera igual a la memoria disponible en el servidor, pero no, eso no sucedió, lo que pasó fue que eventualmente dijeron: Como el costo de revisar toda la aplicación para optimizarla es muy grande, la alternativa será contratar una PC virtual con la memoria que necesitamos e instalar ahí el servidor con la aplicación. Yo no sé quién era el responsable de ese proyecto por nuestra parte, pero si a mí me hubieran propuesto eso, los hubiera mandado al diablo y les hubiera dicho que ésa es responsabilidad de la agencia de desarrollo y no tiene por qué costarme un centavo solamente porque no tenían experiencia desarrollando sistemas grandes, pero para fortuna de esta agencia, el líder de proyecto era una persona con total desconocimiento de temas técnicos y aceptó todo lo que le propusieron, y así fue liberado después de muchos meses el sistema: Un monstruo traga memoria que trabajaba a velocidad de caracol.
Al menos yo aprendí en cabeza ajena, y me di cuenta que en realidad es una tontería integrar código abierto solamente porque es gratis. Al final el costo puede ser mucho más alto, y eso sin mencionar que la realidad es que no porque sea un código abierto existe una cantidad infinita de programadores que lo utilicen. Pero yo sospecho que esa fue la misma mentalidad que ha seguido la mayoría de las empresas, y digo sospecho porque solo observa las ofertas de trabajo que publican hoy en día, donde los requerimientos más populares son: Hibernate, Spring, Spring Boot, Node.js, Angular, y muchos más, y todos de código abierto. No estoy diciendo que deberíamos ser enemigos del código abierto, pero tampoco hay que exagerar a un nivel donde el código abierto se vuelve una obsesión.
¡Hasta la próxima!
Raúl Cosío