Optimización Prematura: El Arte de Complicarnos la Vida
El miedo al éxito
En la década de 1970, el científico de la computación Donald Knuth escribió una frase que se convirtió en un mantra para nuestra industria: "La optimización prematura es la raíz de todos los males en la programación".
A pesar del tiempo, quienes escribimos código seguimos cayendo en esta trampa. Tenemos una idea para un proyecto nuevo, abrimos el editor y, en lugar de programar la solución más directa, nos entra el pánico: "¿Qué pasa si el tráfico crece súbitamente y entran un millón de usuarios de golpe?".
Usar una infraestructura gigante para un proyecto que recién empieza es un desperdicio de tiempo y recursos.
El síndrome de la arquitectura gigante
Impulsados por ese miedo, frenamos el desarrollo del producto real y empezamos a sobre-ingeniar.
En lugar de usar un servidor tradicional y una base de datos relacional que resolverían el problema en una semana, pasamos dos meses configurando una arquitectura de microservicios, balanceadores y bases de datos distribuidas ultra complejas.
Lanzamos el proyecto. Entran 50 usuarios en total durante el primer mes.
Gastamos recursos en servidores para resolver un problema de tráfico que no teníamos. Y lo peor: ahora tenemos una base de código tan fragmentada que agregar una función simple nos toma muchísimo tiempo.
La regla de los tres pasos
El error nace de querer aplicar la ingeniería de gigantes como Netflix a proyectos que recién nacen. Para evitar construir infraestructuras innecesarias, una buena filosofía de desarrollo se resume en tres pasos:
- Make it work (Que funcione): Primero, resolvemos el problema del usuario de la forma más simple y rápida posible para validar la idea.
- Make it right (Que esté bien hecho): Una vez que funciona, refactorizamos. Limpiamos el código y aplicamos buenas prácticas para que sea fácil de mantener.
- Make it fast (Que sea rápido): Solo optimizamos el rendimiento de forma agresiva cuando el sistema realmente lo necesita.
Medir antes de actuar
El secreto del último paso es que no debemos adivinar qué parte de nuestra aplicación es lenta. La optimización real se basa en métricas.
Utilizamos herramientas de monitoreo para encontrar el cuello de botella exacto. Muchas veces, creemos que necesitamos cambiar el lenguaje de programación para ganar velocidad, y al medir descubrimos que solo faltaba agregar un índice en la base de datos.
Complicar nuestra arquitectura hoy por un miedo a un tráfico masivo que quizás nunca llegue, es el camino más rápido hacia la frustración. La mejor ingeniería es la que resuelve el problema actual con la menor cantidad de piezas posibles.
