La trampa del hype
Cada semana hay un nuevo framework, una nueva herramienta, una nueva forma "correcta" de hacer las cosas. Twitter está lleno de hilos explicando por qué deberías migrar a X tecnología inmediatamente.
Después de años cayendo en esa trampa y aprendiendo de mis errores, ahora mi posición es diferente: la mejor tecnología es la que resuelve tu problema con la menor complejidad posible. Y muchas veces, esa no es la última ni la más popular.
Señales de que estás eligiendo por hype
"Todos los grandes lo usan"
Google usa Kubernetes. Eso no significa que tu startup de 5 personas necesite Kubernetes. Google tiene problemas que tú no tienes. Y tiene equipos dedicados a mantener esa infraestructura.
Lo que funciona para empresas con miles de ingenieros probablemente es overkill para tu contexto.
"Es lo que se pide en las ofertas de trabajo"
Las ofertas de trabajo piden la tecnología del momento porque los recruiters copian de otras ofertas. Eso no significa que sea la mejor opción para tu proyecto.
He visto equipos adoptar tecnologías solo porque "así es más fácil contratar", para luego descubrir que nadie del equipo actual la domina y la productividad se va al piso por meses.
"El stack actual está viejo"
¿Viejo significa que no funciona? ¿O significa que no es lo que sale en los blogs?
Hay sistemas en PHP, jQuery, y MySQL que generan millones de dólares y funcionan perfectamente. Reescribirlos en el stack moderno no los va a hacer mejores automáticamente.
Cuándo las tecnologías aburridas son la mejor opción
Cuando el equipo ya las domina
Un equipo productivo en Rails va a entregar más rápido que el mismo equipo aprendiendo Go, aunque Go sea "más rápido". La velocidad de desarrollo importa más que la velocidad de ejecución en la mayoría de los casos.
El costo de aprender una tecnología nueva es enorme: errores de principiante, arquitecturas mal diseñadas, tiempo investigando problemas básicos. Todo eso se traduce en meses de atraso.
Cuando el problema es bien conocido
¿Necesitas un CRUD con autenticación? Eso está resuelto hace 20 años. No necesitas inventar nada nuevo.
¿Necesitas un sistema de pagos? Usa las librerías probadas de Stripe. No implementes tu propia solución con la última tecnología.
Las tecnologías maduras tienen:
- Documentación completa
- Soluciones a problemas comunes en Stack Overflow
- Bugs conocidos y workarounds documentados
- Comunidades activas que pueden ayudarte
Cuando la estabilidad es crítica
En fintech, un bug puede significar que alguien pierda dinero. En healthcare, puede ser peor. En estos contextos, quieres tecnologías probadas en producción por años, no el framework que salió hace 6 meses.
La versión 1.0 de cualquier tecnología tiene bugs. Tú no quieres ser quien los descubre en producción.
Cuándo SÍ tiene sentido adoptar algo nuevo
Cuando resuelve un problema real que tienes
No "podría ser útil algún día". Un problema real, ahora, que no puedes resolver bien con lo que tienes.
Si tu aplicación necesita real-time y tu stack actual lo hace difícil, tiene sentido evaluar algo diseñado para eso. Si tu aplicación no necesita real-time, no adoptes algo solo porque "soporta real-time".
Cuando el costo de migración es bajo
Adoptar una nueva librería de componentes es relativamente barato. Puedes hacerlo incremental, archivo por archivo.
Cambiar de base de datos es carísimo. Cambiar de lenguaje de programación es un proyecto de meses o años.
Evalúa el costo real de adopción, incluyendo:
- Tiempo de aprendizaje del equipo
- Reescritura de código existente
- Nuevos tipos de bugs que van a aparecer
- Tooling que hay que configurar de nuevo
Cuando tienes tiempo para hacerlo bien
Adoptar tecnología nueva durante un crunch de deadline es receta para desastre. Si vas a probar algo nuevo, hazlo en un proyecto con margen para errores.
Lo peor que puedes hacer es adoptar algo nuevo Y tener que entregar en dos semanas. Vas a terminar con una implementación mediocre que nadie entiende.
Mi framework para decisiones técnicas
1. Define el problema primero
No "quiero usar Rust". Sino "necesito mejor performance en este proceso específico".
Si no puedes definir el problema claramente, probablemente no necesitas cambiar nada.
2. Evalúa si lo actual lo puede resolver
Muchas veces la solución no es nueva tecnología, sino usar mejor la que ya tienes. Un índice en la base de datos, un cache simple, refactorizar código ineficiente.
3. Considera el costo total
No solo el tiempo de implementación inicial. También:
- Mantenimiento a largo plazo
- Onboarding de nuevos miembros
- Integración con el resto del sistema
- Debugging cuando algo falla
4. Empieza pequeño
Si decides adoptar algo nuevo, hazlo en una parte no crítica del sistema primero. Aprende los gotchas antes de que afecten lo importante.
Las tecnologías que uso (y por qué)
Después de probar de todo, mi stack actual es deliberadamente "aburrido":
- Next.js/React: No porque sea lo más nuevo, sino porque lo domino y tiene ecosistema maduro
- PostgreSQL: Funciona para el 99% de los casos. No necesito bases de datos especializadas
- TypeScript: El tipado me ahorra bugs. Vale la pena la verbosidad extra
- Tailwind: Controversial, pero me hace productivo. Eso es lo que importa
¿Es el stack perfecto? No. ¿Es el stack con el que más rápido entrego software funcional? Sí.
Conclusión
La madurez técnica no es saber todas las tecnologías nuevas. Es saber cuándo usarlas y cuándo no.
El código más impresionante no es el que usa la última tecnología. Es el que resuelve el problema de forma simple, mantenible, y que cualquiera del equipo puede entender.
La próxima vez que sientas la urgencia de adoptar algo nuevo, pregúntate: ¿estoy resolviendo un problema real o estoy siguiendo el hype? La respuesta honesta te va a ahorrar mucho tiempo.
