Decisiones como los cangrejos…

Por alguna razon me acabo de acordar un mail que me mando mi amiga que esta en Chile preguntando que seria necesario para migrar de C++ a C. Eso fue hace unos años pero aun asi sirve como ejemplo para ver como algunas decisiones se toman de manera poco estrategica.

El caso es que se tenia un proyecto desarrollado para una plataforma de comunicaciones, y habia sido desarrollado en C++ (osea orientado a Objetos) pero que por una migracion se requeria tener la misma funcionalidad en una plataforma cuyo compilador solo soportaba C (estructurado) y no C++. Conteste a mi amiga de que habria que convertir las clases a estructuras y definir una nomenclatura que sirva para identificar las funciones para que mapeen los metodos de las clases…. pero en fin.. tenia un pinta de ser una tarea titanica, suerte que al final ella no se hizo cargo.

Esto viene a proposito de tendencias que vemos en las empresas, anclarse a plataformas obsoletas o con fabricantes absorbidos/desaparecidos, todo porque se considera que la logica de negocio ya esta estable, que el costo de migrar seria superior y la mas comun… “es que el mainframe es mas robusto”, “esta nueva tecnologia aun no esta probada” todas son excusas que al final se agravan en los casos de integracion de sistemas.

Los efectos visibles los habremos visto frecuentemente, sistemas criticos dependiendo de miles de lineas de codigo en COBOL, mismos que requieren constantes ajustes y mantenimientos que no pueden beneficiarse de conceptos como arquitectura de servicios, XML, WebServices, y en algunos casos ni siquiera Orientacion a Objetos, esto porque se siguio un proceso de mantenimiento continuo mas no de evolucion de los sistemas, a lo sumo una adaptacion de interfaces para su conexion con nuevas tecnologias, pero…. cambiar mi amado y superpoderoso mainframe con COBOL? ni hablar!!! Un resultado muy visible se vio cuando hubo que solucionar el problema del año 2000, se comentaba que en algunas empresas se tuvo que traer a programadores jubilados para que estuvieran en el proceso de parche, ya que estos eran quienes habian estado durante el desarrollo original.

Cierto, no es que debamos cambiar por cambiar, sino hacer un analisis de las nuevas tecnologias y sus perspectivas de evolucion, no vaya a ser que pase como quienes apostaron por las WebClasses, ColdFusion, o Visual J++, pero a estas alturas… desconfiar de los servidores de bases de datos relacionales??? (pues si a estas alturas hay quienes aun les tienen alergia).

Ironicamente se da el caso de empresas que acometen renovaciones periodicas de ciertas partes de su plataforma, especialmente la de los usuarios finales, pero claro… el nucleo hecho en mainframe… ni tocarlo, pero eso si.. a montar toda una super arquitectura Web mediante SOA y XML, como me paso en un proyecto donde todo era muy moderno en teoria, pero el mainframe era incapaz de generar XML para ser consumido (por lo menos eso podria hacer, no?) asi que otro modulo era el de conversion de tramas, eso si… no les falto valor para introducir AJAX en las etapas finales del proyecto…. alucinante de veras, se pasan defendiendo al mainframe por ser algo “ya probado” pero a la hora de los loros meten una tecnologia recien probandose… en las etapas finales del proyecto.

El caso es de que a veces se pierde la vista de que las Tecnologias de la Informacion deben cumplir un rol como ventaja competitiva para la organizacion, o en todo caso facilitador de sus procesos, pero lamentablemente vemos como persiste la dependencia a los “legados” lo cual lleva a problemas de mantenimiento debido al parche tras parche, y ahora la dificultad (y el mayor costo que eso conllevara) para encontrar personal dispuesto a trabajar en dichas tecnologias, como se manifiesta en el hecho de que buena parte de los reclutamientos que hizo una empresa española en Peru fueron de programadores para mainframe, es que claro… las nuevas generaciones saben de que va eso asi que evitaran tratar de enfocar su carrera en el uso de dichas tecnologias, y si en Peru aun es factible encontrar este tipo de programadores… es un sintoma de que algo se esta haciendo mal por ahi.

Joder con el puto AJAX de los cojones!!

Como decia un profesor en el IE “mis muertos los cuento frios”, asi que recien ahora puedo contar algo de mi experiencia profesional reciente, que espero que sea de utilidad para el que le interese la gestion del desarrollo de software.

Con todos estos años de practica, algunas cosas se te quedan claras en base a las experiencias pasadas y tratas de aplicarlas en la medida de lo posible, lamentablemente a veces no se esta en la posicion de aplicarlas y este fue el caso.

Como decia, algunas cosas se te quedan claras y con fundamento, en este caso tenia claro que avanzado un proyecto no es conveniente meter una tecnologia nueva salvo que: Estuviera focalizada en un sector con poca interaccion con el resto de la aplicacion, o que estuviera claro que fuera completamente compatible y/o evolutiva de la tecnologia empleandose en ese momento.

Pareceria una politica simple y razonable de seguir, pero quienes estan en informatica sabran que estas dos palabras no estan precisamente a la orden del dia en la gestion de proyectos, aunque debo reconocer que he tenido jefes que sin tenido la habilidad suficiente como para llevar razonablemente el proyecto y los intereses de los stakeholders.

Se trataba de una aplicacion Web para uso interno, donde como consecuencia del alto numero de datos a ingresar eran frecuentes las idas y vueltas al servidor, ocasionando un efecto de parpadeo o “pantallazo” que era incomodo para algunos usuarios. Sin ir al detalle tecnico (conocido para quienes conocen esta tecnologia) sabran que este efecto es consecuencia del modelo que trajo ASP.NET el cual es necesario para brindarnos una facilidad de desarrollo que habiamos perdido cuando se paso de la Programacion Visual (con VB, Delphi o PowerBuilder) a desarrollar para la Web (quien ha programado CGIs, ASP Clasico o PHP3 sabe de lo que hablo).

Lamentablemente las quejas salieron cuando la estructura de la aplicacion estaba completada en un 80%, asi que poco se podia hacer (yo proponia aumentar la capacidad de procesamiento del servidor), hasta que alguien planteo la posibilidad de usar lo que recientemente se ha dado por denominar AJAX (aunque las tecnologias base han estado disponibles desde hace tiempo) para solucionar el problema y claro …. se dio el visto bueno a dicha propuesta.

Como ya he comentado la aplicacion ya habia avanzado bastante pero aun faltaban ajustes finales, por lo que se inicio un desarrollo paralelo, por un lado se trataba de replicar en AJAX la funcionalidad existente, y por otro lado se continuaba el refinamiento en la tecnologia actual hasta llegar a un punto de convergencia para integrar las modificaciones hechas en paralelo (las cuales tenian que apuntarse con sumo cuidado).

Cuando correspondio a que se manipulara mis modulos recien cai en la cruda realidad, trabajar con AJAX (al menos en la version que se utilizo) involucraba un paso atras en lo que habiamos ganado en funcionalidad de desarrollo con ASP.NET (si quieres la explicacion marciana ve al final del articulo) siendo mucho mas complicado depurar la aplicacion obligandote a mantener un doble juego de variables y de logica de la pantalla, ya que como la tecnologia se inyecto estando la aplicacion avanzada no hubo alternativa, siendo otra la situacion si se hubiera tenido un desarrollo en AJAX puro desde el principio o con modelo ASP.NET como lo teniamos.

La desesperacion para tratar de ajustar y que vuelvan a funcionar cosas que YA ESTABAN BIEN nos llevo en algunos momentos a decir la frase que titula este post, porque de veras…. era desesperante que cosas sencillas como asignar u obtener el valor de un control de una variable fuera algo complicadisimo.

En honor a la verdad debo decir que el proyecto salio adelante y ya esta en produccion, pero no dejo de pensar que los dos meses (como minimo) que se agregaron al proyecto multiplicado por el coste de 2 recursos (igualmente como minimo) hubiera podido alcanzar para la adquisicion de un mejor servidor, sin el inconveniente de la poca mantenibilidad que adquirio el proyecto.

En resumidas cuentas con ASP.NET uno se acostumbra a manipular directamente los valores de los diversos controles que estan en la pantalla, con AJAX tareas simples como requerian la regeneracion de un XML con el conjunto de valores de los controles, siendo necesario implementar funciones (mas complejas) para recuperar los valores utilizados pues los valores que usa por defecto ASP.NET se vuelven completamente inutiles, mas aun: como en este caso teniamos logica duplicada en ciertos momentos debia hacerse una multiple verificacion para saber que conjunto de variables estaba informado, so pena de que la aplicacion fallara.