Cómo mantener la vanguardia tecnológica

Cómo mantener la vanguardia tecnológica

¿Qué coloca a una empresa a la vanguardia? ¿Cómo se implementan nuevas tecnologías? ¿Cómo se sabe cuáles, en qué momento y cómo lo enfrenta el equipo? Aún más importante: ¿Por qué es necesario? Además del reto que representa lo anterior, hay que  balancearlo con la entrega puntual de requerimientos.

A lo largo de mi carrera como ingeniero de software viví distintas etapas en varias empresas, desde aquéllas con un stack muy estable pero poco innovador, otras donde se podían hacer cambios pero sin asumir muchos riesgos, hasta mi empleo actual, donde he tenido la fortuna de ser parte de una gran transformación y con la libertad de promoverlo directamente.

El camino

Para llegar al punto, cuento un poco de mis inicios. Hace años, todavía sin mucha experiencia —solo con algunos proyectos universitarios con PHP y Jquery—, ciertamente no tenía visibilidad de temas muy de negocio. Si me pedían hacer un sitio web para un restaurante, lo haría con lo que me lo permitiera en menos tiempo y, posiblemente, no volvería a moverle en meses salvo por cambios típicos de textos o imágenes. Usábamos templates o tomábamos de base proyectos previos. No es que eso esté mal sino que, al menos yo, no me preguntaba cómo ese código podría  ayudar en algo si lo hiciera diferente. Llegaba a ser algo mecánico.

Recuerdo cuando llegó un nuevo compañero con algo más de experiencia y propuso un framework (cakePHP). Me interesó ver por qué lo eligió, si le demoraría más completar el trabajo ya que recién lo estaba aprendiendo. Platicando me hizo ver todo lo que se podía hacer con él: podía representar una curva de aprendizaje al principio, pero más adelante agilizaría el desarrollo.

Este primer acercamiento me abrió la visión para conocer luego otros frameworks, como Laravel que me ayudó mucho en futuros proyectos. Pero estoy hablando de cosas de programador; ningún cliente me pidió alguna vez uno en específico, salvo por wordpress. ¿Esto era estar a la vanguardia? En este punto, el criterio era más por mi agilidad como desarrollador.

Hablo de una época convulsa en cuanto al desarrollo web. Todo lo podías hacer con Jquery; nadie lo cuestionaba. Luego conocí Angular, React, Ember y Vue, que me abrieron aún más puertas. Quienes estamos en el frontend, principalmente, sabemos la ventaja tanto en velocidad de desarrollo como en calidad del mismo al tener una mejor estructura, funcionalidades predispuestas para implementarse y además una comunidad de desarrolladores al alza que proveía de nuevos módulos para reutilizar.

En ese entonces me di cuenta de que usar nuevas herramientas para un desarrollo veloz y un funcionamiento eficiente era una baza para vender, al tiempo que tener rápido su nuevo sistema representaba una ventaja competitiva para el cliente.

Llegando a mi empleo actual, me tocó empezar con React y vi también el uso de nuevos paradigmas, como por ejemplo un uso más extendido de herramientas de AWS especialmente para el despliegue del proyecto, servidores, almacenamiento, etc. Una vez más, buen balance en velocidad y calidad entraban en juego, pero también algo extra: un ambiente que propiciaba nuevas tecnologías, probar otros enfoques no solo en un proyecto nuevo sino para mejorar lo ya existente.

Mi momento de involucrarme a conciencia fue cuando decidí implementar Vue en cierto proyecto por sobre React. ¡Casi todo lo futuro siguió ese camino! Me consta la felicidad del equipo al empezar programando con un framework que requiere mucho menos setup inicial y con muchas características listas para avanzar rápido.

En un momento dado, fuimos reconocidos por crear desarrollos de calidad internacional y en tiempo récord, soportando millones de visitas cada mes. ¿Hubiera sido posible sin esas tecnologías que hace pocos años aún eran poco conocidas o inexistentes?

Bueno, ¿qué dicen los bancos y otras instituciones donde abundan sistemas legacy? Aunque son la base de muchos sistemas críticos, funcionan y soportan millones de transacciones usan, sin embargo, lenguajes antiguos, ¿Por qué no opinaría que están a la vanguardia?

Pocas pueden darle mantenimiento a un sistema hecho en un lenguaje antiguo.  Funciona, pero no hay nada nuevo que aporte valor, que haga más rápido su desarrollo, que pueda evolucionar a la par de las necesidades del negocio— incluso es muy costoso migrar o ya está en el punto donde mejor no moverle si así ya funciona— Esto implica que la empresa avanzará lento, innovará menos… una desventaja.

Más de una vez hemos migrado de un stack a otro: entre tipos de bases de datos, servicios de AWS, nuevas versiones de Vue, monolitos a microservicios, frontends robustos a microfrontends, etc. Esto no es un capricho, es una necesidad para seguir generando valor.

Y hablando nuevamente sobre el frontend, incluso con lo que nos ha gustado Vue, no nos detuvimos para elegir otros frameworks (como Preact, Svelte y Astro) para situaciones donde identificamos su valor.

No obstante, como en todo proyecto llegamos a cierto punto de estabilidad donde te cuestionas si mejorarlo o solo mantenerlo con los cambios que se soliciten. ¿Por qué dedicarle tiempo a reescribir código?

Pues porque hay variables que entran en juego sobre todo al ganar responsabilidad; comienzas a tener visibilidad de temas a nivel negocio. Ves que si el cliente necesita soporte en varios temas, así como que rápidamente actives o desactives cierta característica, entonces la empresa no dirá cómo estructurarlo pero se espera eficiencia. En otras palabras, es tu deber promover lo más adecuado, si el stack elegido facilita esto y además adelantarte en lo posible. Eso es promover la vanguardia tecnológica.

Recomendaciones

Les he contado sobre el camino que me llevó a estar más consciente y promover dicha cultura de vanguardia. De esto extraigo algunas recomendaciones:

Refactors

Son un arma poderosa tanto para mejorar la calidad de código como para mantenerlo vigente y escalable, es decir, facilitando la adición de futuros cambios.

Con el apuro de liberar el último requerimiento urgente a producción, es posible que el código no sea el mejor. Pero pasando la tormenta se puede mejorar.

Un código limpio nos habilita para que sea sencillo y eficiente añadir nuevo código, al tiempo que facilita que más compañeros colaboren y sigan un camino. ¿Te ha pasado que antes de completar el requerimiento tuviste que hacer más cambios o leerlo varias veces para comprender? Este tiempo extra se previene haciendo buen código y cuando no se logra a la primera, entra el refactor.

Qué, cómo y cuándo refactorizar se convierte en un tema cultural del equipo. Puede ser algo progresivo e iterativo: archivo que toco, archivo por mejorar; archivo que se mueve mucho, archivo que puede reestructurarse hasta estabilizar. Una guía clara es con base en la tasa de cambios y complejidad, como se ve en la siguiente imagen:

Fuente: https://modlogix.com/blog/legacy-code-refactoring-tips-steps-and-best-practices/

Equipo

¡Escucha al equipo! Esto es importante, sobre todo conforme ganas responsabilidad ya sea como Sr. o Tech Lead. Del equipo salen muchas ideas que aportan a la evolución del producto. El equipo  conoce su código y herramientas mejor que nadie. Al mantener canales de discusión abiertos y el oído atento para reconocer la propuesta que mejor encaja se hallan las mejores soluciones.

Conferencias y meetups

Ya sea virtual o presencial, son valiosas fuentes de ideas y de nuevas tecnologías que promueven la comunidad. Son una ventana a tendencias que permiten ver caminos viables para dirigir nuestra estrategia.

Inversión en ingeniería

Otra forma de verlo es como una inversión que dará frutos. Por ejemplo, migrar nuestra infraestructura a Kubernetes representa un gran esfuerzo, tiempo, curva de aprendizaje, desarrollos y monitoreo, pero al final habremos puesto en práctica una arquitectura que nos permite administrar, escalar y responder mucho mejor al inmenso tráfico que recibimos.

O bien, si migramos de Vue-cli a Vite cuando el segundo aún estaba muy limitado en su integración, pero sabiendo sus ventajas en velocidad y apostando con seguridad a que el mismo equipo creador de Vue lo seguiría mejorando, el resultado —meses después— es un setup en nuestros proyectos de front que, además de eficiente, es sencillo configurar e integrar con otras herramientas. Garantizamos velocidad, calidad y escalabilidad y, por ende, seguimos a la vanguardia.

Evaluación

¿Por qué una tecnología en lugar de otra?, especialmente en nuestro ámbito de desarrollo donde constantemente surge algo nuevo.

Aunque solucione algo en el presente, quizá a largo plazo tenga desventajas. Si elijo una herramienta que casi no recibe contribuciones o su equipo la tiene olvidada, es muy posible que no sea lo que necesito, pues en el futuro habrá que cambiarla —incluso antes de lo previsto— para recuperar la inversión.

Es por eso que elegiremos aquello que sea más viable entre costos, esfuerzos, compatibilidad, tiempos, y otras variables.

Abrir puertas

Lo dicho antes nos lleva a contemplar nuestro deber de promover siempre lo mejor. Estar a la vanguardia no es solo cumplir con los objetivos del presente, sino prepararnos a futuro.

Otro ejemplo: Usamos mucho Jest para pruebas unitarias y mencioné que usamos Vite. El mismo equipo también ha creado Vitest, el cual es intercompatible con Jest pero va más allá al hacer mancuerna con Vite. Esto lo convierte en un camino a seguir pues tenemos más seguridad para el crecimiento del proyecto. Garantizamos a futuro que tendremos cubierta y funcional la parte de pruebas, apoyando finalmente a una mayor disponibilidad de los servicios.

Pragmatismo

Sin embargo, el negocio debe continuar. En casos urgentes, es difícil justificar dedicarle tiempo a una herramienta o migración que nos representa una curva de aprendizaje, más si ya tenemos expertise con lo actual. Entonces avanzamos con lo que nos hace productivos en ese momento. Una forma de facilitar la vanguardia pese a este escenario es estructurando los proyectos de tal forma que puedan actualizarse gradualmente.

Por ejemplo: ¿pasar a Vue 3 o añadir Typescript? Hay pasos progresivos más alcanzables que hacerlo de golpe. Tal vez configurar lo más básico, probar, liberar, cambiar el siguiente componente e iterar.

Dinámicas y transferencia de conocimiento

Finalmente, ciertas actividades grupales nos permiten conocer lo que hacen otros equipos, como a través de pairs programmings o code reviews.

Aquí conocemos lo nuevo que manejan, sus retos y soluciones dadas, por qué han elegido una u otra herramientas. Esto facilita la transferencia de conocimiento que eventualmente ayuda a tomar mejores decisiones.

Conclusiones

La vanguardia tecnológica es un camino, el cual seguimos y promovemos. Se consigue, entre otras formas, eligiendo las tecnologías y arquitecturas adecuadas no solo por ser modernas, sino porque proveen soluciones tanto en el presente como a futuro.

Aun cuando representen esfuerzo extra, reconocemos el crecimiento que otorga profesionalmente, lo que permite al negocio seguir siendo competitivo. Incluso si no es parte de un requisito, como miembros  del equipo estamos conscientes de nuestra misión de ir más allá, recomendando lo mejor para la evolución del producto.