En momentos como este recuerdo que al momento de salir del colegio e ir en búsqueda de opciones de estudio se hablaba de la ingeniería de sistemas como "la carrea del futuro". 17 años después no sé si este era el futuro del que se hablaba pero me enerva que los sitios donde trabajo sigan estando en el pasado.
Para ponerlos en contexto yo me desempeño como programador o desarrollador en lenguaje Java. Al igual que mi carrera no fue mi primera opción pero acá estoy. Java fue lanzado en 1995 y yo lo conocí en su versión 1.4 que fue lanzada en 2002. Luego aprendí las novedades de Java 5 (así se llama la versión que continua) que salió en 2004, intenté certificarme sin éxito para Java 6 que salió en 2006, y leí algunas cosas de Java 7 que salió en 2011. Desde entonces salió Java 8 en 2014 y se espera la salida de Java 9 en 2017. E increíblemente las empresas siguen trabajando con tecnologías java 1.4 y encuentro código más o menos reciente con sintaxis de Java 1.4.
Así que a día de hoy existen empresas con casi 14 años de atraso en tecnología al igual que los programadores que escriben el código. Participé en una migración (actualización) de unas aplicaciones que aunque usan la máquina virtual de Java 7 (recuerden, 2011) siguen exigiéndole al programador que utilice sintaxis de Java 5 (2004). Así que la dichosa migración en realidad solo actualizó la tecnología usada en 2 años.
La segunda pega de la que quiero hablar está ligada a la primera y es el mantenimiento de
dichas aplicaciones. En programación, no hay una sola forma de hacer las cosas. Habrán formas como programadores hay por lo que se deben definir estándares de programación enfocados en el manejo de buenas prácticas y patrones de diseño entre otras. Y aún así, aunque a uno como desarrollador le de pereza, la documentación es fundamental para el mantenimiento del código pero no todos los sitios los usan y es ahí cuando a uno como desarrollador le toca sufrir.
En un sitio donde trabajé, me pusieron a hacer el mantenimiento de una aplicación. Creo que debía hacer que la aplicación fuese compatible con Firefox 18, y para que se imaginen, Firefox va por la versión 44 (en ese tiempo iba por la 32). Para ese tiempo ya existía Java 7 pero esta aplicación usaba Java 1.4 y además usaba JSF 1.2, GWT 1.7, Spring, Hibernate, EJB y no recuerdo que otras tecnologías que convertían a la aplicación en un revuelto de partes cual Frankenstein. Como ya podrán suponer no pude poner dicha compatibilidad, en parte porque después de un mes de estar intentándolo ya me había desanimado, en parte porque cada vez que sugería algo me decían que no porque me podía tirar otra cosa. Como también podrán suponer no había documentación.
¿Qué hacer entonces? Se supone que las migraciones son costosas, pero ¿cómo no van a ser costosas si esperan más de 10 años para hacerlas?
Si yo fuese director de sistemas tendría un grupo de ingenieros trabajando en innovación, probando nuevas tecnologías y buscando formas más eficientes de hacer las cosas. No me daría miedo en tener cierta dispersión en cuanto a versiones de las aplicaciones pues eso me obligaríaa actualizar o migrar las versiones que se vayan quedando.
Si entendió lo que dije, le ruego me deje sus comentarios con sugerencias sobre que hacee. También acepto crítica constructiva.
Para ponerlos en contexto yo me desempeño como programador o desarrollador en lenguaje Java. Al igual que mi carrera no fue mi primera opción pero acá estoy. Java fue lanzado en 1995 y yo lo conocí en su versión 1.4 que fue lanzada en 2002. Luego aprendí las novedades de Java 5 (así se llama la versión que continua) que salió en 2004, intenté certificarme sin éxito para Java 6 que salió en 2006, y leí algunas cosas de Java 7 que salió en 2011. Desde entonces salió Java 8 en 2014 y se espera la salida de Java 9 en 2017. E increíblemente las empresas siguen trabajando con tecnologías java 1.4 y encuentro código más o menos reciente con sintaxis de Java 1.4.
Así que a día de hoy existen empresas con casi 14 años de atraso en tecnología al igual que los programadores que escriben el código. Participé en una migración (actualización) de unas aplicaciones que aunque usan la máquina virtual de Java 7 (recuerden, 2011) siguen exigiéndole al programador que utilice sintaxis de Java 5 (2004). Así que la dichosa migración en realidad solo actualizó la tecnología usada en 2 años.
La segunda pega de la que quiero hablar está ligada a la primera y es el mantenimiento de
dichas aplicaciones. En programación, no hay una sola forma de hacer las cosas. Habrán formas como programadores hay por lo que se deben definir estándares de programación enfocados en el manejo de buenas prácticas y patrones de diseño entre otras. Y aún así, aunque a uno como desarrollador le de pereza, la documentación es fundamental para el mantenimiento del código pero no todos los sitios los usan y es ahí cuando a uno como desarrollador le toca sufrir.
En un sitio donde trabajé, me pusieron a hacer el mantenimiento de una aplicación. Creo que debía hacer que la aplicación fuese compatible con Firefox 18, y para que se imaginen, Firefox va por la versión 44 (en ese tiempo iba por la 32). Para ese tiempo ya existía Java 7 pero esta aplicación usaba Java 1.4 y además usaba JSF 1.2, GWT 1.7, Spring, Hibernate, EJB y no recuerdo que otras tecnologías que convertían a la aplicación en un revuelto de partes cual Frankenstein. Como ya podrán suponer no pude poner dicha compatibilidad, en parte porque después de un mes de estar intentándolo ya me había desanimado, en parte porque cada vez que sugería algo me decían que no porque me podía tirar otra cosa. Como también podrán suponer no había documentación.
¿Qué hacer entonces? Se supone que las migraciones son costosas, pero ¿cómo no van a ser costosas si esperan más de 10 años para hacerlas?
Si yo fuese director de sistemas tendría un grupo de ingenieros trabajando en innovación, probando nuevas tecnologías y buscando formas más eficientes de hacer las cosas. No me daría miedo en tener cierta dispersión en cuanto a versiones de las aplicaciones pues eso me obligaríaa actualizar o migrar las versiones que se vayan quedando.
Si entendió lo que dije, le ruego me deje sus comentarios con sugerencias sobre que hacee. También acepto crítica constructiva.