En lo que respecta al mundo del desarrollo Java me he encontrado con empresas que son muy conservadores con respecto a actualizarse a tecnologías más modernas, por diversas razones que mencionare abajo, claramente hay un riesgo en actualizarse y en no.
Actualizarse
En ocasiones empresas grandes suelen darse cuenta que realmente un departamento IT es indispensable, no obstante, carecen de expertos del tema. Me ha tocado entrar a equipos donde las únicas personas calificadas eran aquellas que se pusieron a googlear código para dar una mano en la empresa. En Latinoamérica poco a poco crece más el nivel en cuanto a desarrolladores, pero algunas empresas aún son nuevas en esto, insertándose hace pocos años en el país. Para la gente tradicional actualizarse lleva buscar nuevo equipo o capacitación para el mismo, esto representa un gasto de dinero tanto en capacitación como en migración; hasta gasto de tiempo si hablamos también del entorno de trabajo local o en nube. Día a día aparecen nuevas tecnologías y dedicarse a ellas requiere un tiempo, no obstante, muchos equipos están con tiempo marcado para la realización de varios proyectos, por lo cual no llega a ser lo más óptimo en un equipo pequeño que necesita entregar proyectos y no tiene tiempo para actualizarse, siempre hay muchas dudas de como funcionaran y como se asentaran en el mercado.
No actualizarse
Si bien esta ese dicho de "lo barato sale caro", es algo similar en esto, sin embargo, el Stack depende mucho del desarrollo que haya que crear/mantener. Por la solución a anterior que es simplemente "no actualizarse, dejarlo todo como funciona", si bien puede funcionar, en el caso de que esto siga creciendo va a llegar una etapa en la que se vuelva menos practico, es como cuando llega ese momento en el departamento que es solo "apagar incendios", problemas de infraestructura y desarrollo siempre fueron rápidos y cómodos, pero las necesidades cambiaron, la empresa creció y las aplicaciones demandaron nuevos cambios que en su Stack original, tenían sus primeros incidentes encontrándose con soporte que pudo haberse evitado, pero por algo esto sirve como experiencia para cada empresa. Cabe destacar que se excluye aplicaciones de legado, pero si tenemos que hablar aplicaciones modernas que usen un Stack donde por ejemplo no se implemente Hibernate (hablando en el entorno de Java) nos limitamos mucho a no poder usar Frameworks, estos y las librerías en si son extensos y nuestro desarrollo debe estar apto para tal ampliación.
En otra ocasión estaba en desarrollo con una aplicación de java 6 que aun usaba Jars en la carpeta Lib, si bien yo mismo considero Gradle antes que Maven, considero que al día de hoy usar maven es indispensable sea un proyecto JSP, Struts 2 o semejantes. Usar Maven o Gradle nos es indispensable para Frameworks que nos hacen el desarrollo más fácil con Spring Boot y desplegar aplicaciones modernas y escoger el camino sencillo a las arquitecturas de micro servicios. Los micro servicios y la automatización de los mismos desarrollos tarde o temprano llegaran a una empresa en crecimiento.
El no optar por usar Maven o Gradle y/o Frameworks, llegara un momento en el que coste será muy alto, donde la inversión que habría seria considerable y donde estará la duda de si realmente la podremos abordar; sus consecuencias, graves.
Es mucho más razonable ir avanzando paso a paso y realizar los esfuerzos de manera paulatina que encontrarnos con situaciones en las que el salto a la actualización es tan alto y arriesgado y expuesto a que haya pocas posibilidades de que todo salga bien.
Top comments (0)