No existe una tecnología perfecta, solo decisiones con trade-offs mejor entendidos.

El mundo de la tecnología está en constante cambio. Resulta sorprendente pensar que computadores como la ENIAC o la UNIVAC estaban reservados para un público muy selecto, mientras que hoy es común tener una computadora en casa, ver a alguien trabajar con un portátil en un café o comunicarse con alguien a miles de kilómetros gracias a uno de los resultados más útiles de la nanotecnología: el teléfono móvil.

De forma similar, hay un área que también avanza a pasos gigantescos para hacer posible todo esto: la ingeniería de software. Tener el mejor hardware no sirve de mucho si el software no es capaz de aprovecharlo. Sería como tener un vehículo con motor turbo V8, pero con llantas que no pueden superar los 80 km/h. ¿Cómo aprovechar ese motor si no puedes ir más rápido?

En software, prácticamente cada día aparece algo nuevo: un framework, una librería, un workaround para un bug conocido o incluso un nuevo lenguaje de programación.

Con este flujo constante de novedades, he observado que en los equipos de desarrollo suelen aparecer tres perfiles al momento de adoptar tecnologías:

• Equipos que adoptan nuevas tecnologías tan pronto las descubren, sin evaluar cómo su producto se verá afectado a largo plazo.

• Equipos que se toman el tiempo de analizar, probar y validar si esa tecnología realmente aportará valor y escalabilidad.

• Equipos que se resisten al cambio, ya sea por miedo, por dependencia de sistemas legacy o por la curva de aprendizaje.

Mi observación se centra en el primer perfil: aquellos que introducen novedades sin considerar cómo su producto escalará con el tiempo.

Es cierto que proyectar un producto a 10 o 20 años es complejo. La mayoría cambia drásticamente en sus primeros años debido a nuevas necesidades de los usuarios y a la competencia. Entonces surge la pregunta: ¿cómo asegurar que un producto podrá escalar en el futuro con las tecnologías escogidas?

No hay una única respuesta, pero un caso interesante es el de Xamarin.Forms. En sus inicios, prometía algo cercano al “santo grial”: write once, run anywhere. La comunidad se entusiasmó rápidamente. Sin embargo, con el tiempo comenzaron a aparecer problemas: renderizados redundantes, bajo rendimiento en Android y una sobreingeniería considerable incluso para tareas simples como personalizar un botón. Claro, Xamarin.Forms logró parte de su promesa pero la complejidad fue creciendo con el tiempo.

Muchos equipos que habían apostado por Xamarin.Forms terminaron migrando a otras tecnologías, invirtiendo tiempo en reescribir sus bases de código. Finalmente, Microsoft realizó cambios profundos y lo transformó en .NET MAUI, pero el proceso de migración resultó complejo, y muchos equipos optaron por rehacer sus aplicaciones desde cero, en algunos casos usando Flutter.

Todo esto ocurrió en aproximadamente 8 años: desde su lanzamiento en 2014 hasta la transición a MAUI en 2022. Ahora, imagina que tu sistema, del cual dependen 29,000 usuarios, se enfrente a algo como esto justo cuando hay enfocarse en enfrentar a la competencia porque tienen las funcionalidades que tu sistema no tiene y sabes que será costoso el implementar los nuevos requerimientos en una tecnología de la que pronto tendrás que migrar.

¿A qué quiero llegar con esto? No se trata de desacreditar una tecnología o empresa, sino de comprender a profundidad la pregunta inicial: ¿cómo tomar mejores decisiones tecnológicas a largo plazo?

Algunos puntos a considerar:

• Revisar el historial de bugs y fixes del repositorio.

• Evaluar el soporte y la adopción por parte de la comunidad.

• Analizar cuánto tiempo lleva la tecnología en el mercado.

• Verificar su compatibilidad con el stack del equipo o empresa.

Entre todos estos factores, hay uno que suele destacar: observar cómo la propia empresa que promueve la tecnología la utiliza.

Es una idea simple: ¿confiarías en un doctor que recomienda algo que él mismo no practica?

En el caso de Xamarin.Forms, Microsoft lo promovía, pero las aplicaciones que desarrollaron internamente con este framework eran muy pocas. Eso, en retrospectiva, es una señal de alerta.

En contraste, tecnologías como React o Flutter han crecido, en parte, porque las empresas que las respaldan las utilizan en productos reales y a gran escala. No se trata de caer en la lógica de “si lo usan en Silicon Valley, yo también”, sino de analizar cómo esas tecnologías han evolucionado y escalado con el tiempo.

Elegir una tecnología no es solo resolver el problema de hoy, sino entender cómo evolucionará mañana. Así como no usarías cualquier herramienta para clavar un clavo, tampoco deberías elegir cualquier tecnología para construir un sistema.

Hoy en día, con herramientas de inteligencia artificial como Claude, es posible generar aplicaciones en días. Eso complica aún más el problema porque ya podemos implementar todo justo ahora sin evaluar las implicaciones futuras que cada implementación pueda tener en el futuro, si los módulos cumplen con principios de arquitectura limpia y escalable o si tenemos dominio de la tecnología que Claude nos ha sugerido utilizar. Por ello, aveces veo que los equipos que tienen dominio en múltiples tecnologías pueden tomar mejores decisiones, ya que no están limitados a “lo que conocen”, sino que pueden evaluar distintas opciones y elegir la más adecuada tanto a corto como a largo plazo.

La complejidad de los sistemas siempre crecerá con el tiempo: nuevos módulos, nuevos requerimientos, nuevos escenarios. La diferencia está en que esa complejidad no se convierta en una desventaja por una mala decisión tecnológica inicial.

La complejidad siempre crecerá. La verdadera decisión está en si la tecnología elegida crecerá contigo… o en tu contra.