Primero hazlo, luego hazlo bien, luego hazlo mejor
Los ingenieros debaten el popular mantra de “primero haz que funcione, luego hazlo bien, luego hazlo rápido”, sopesando la prototipación rápida y los MVP frente a los costos a largo plazo de la deuda técnica y los errores arquitectónicos. Muchos sostienen que el rendimiento, la accesibilidad y la mantenibilidad deben considerarse antes de lo que sugiere este lema, citando ejemplos como las aplicaciones basadas en Electron y los trucos “temporales” que se vuelven permanentes. Otros responden que, en la mayoría de los entornos comerciales, lanzar algo “lo suficientemente bueno” rápido es racional, porque muchos productos nunca sobrevivirán lo suficiente como para justificar una reescritura completa o una optimización profunda.
Interpretaciones del mantra
- Se ofrecen muchas variaciones:
- “Haz que funcione, hazlo bien, hazlo rápido.”
- “Hazlo posible → agradable/probable → rentable/barato.”
- “Haz que funcione → hazlo bien → hazlo rápido (si hace falta).”
- “Haz que funcione → funcione bien → se vea bien.”
- Varios comentaristas sostienen que “bien” y “rápido” a menudo están entrelazados; las decisiones sobre la API central y las estructuras de datos pueden bloquear el rendimiento, obligando después a rehacer casi todo.
- Otros ven “rápido” como un paso distinto y posterior, habilitado por una API limpia y estable que te permite cambiar implementaciones sin alterar el comportamiento.
Corrección, rendimiento y arquitectura
- Muchos enfatizan primero la corrección: un programa rápido que produce resultados incorrectos no sirve.
- Algunos afirman que la mayoría de los problemas de rendimiento son locales (consultas, funciones) y se pueden corregir sin re-arquitecturar.
- Otros insisten en que el rendimiento moderno es en gran medida arquitectónico; si no diseñas para la eficiencia desde el principio, la “optimización” posterior se convierte en una reescritura.
MVP, iteración y “lo suficientemente bueno”
- Hay un fuerte apoyo a “lanzar rápido, iterar rápido”: la primera versión descubre el problema real; las pasadas posteriores refinan y optimizan.
- Los críticos señalan que el código “prototipo” o “temporal” rara vez se descarta; las chapuzas se vuelven permanentes por la presión del negocio y la priorización.
- Varios destacan que el software sirve a necesidades empresariales; si algo es “lo suficientemente bueno” para los clientes y los ingresos, es difícil justificar reescrituras más profundas.
Electron y el uso de recursos
- Electron se usa como caso de estudio central:
- Lado pro-Electron: una enorme base de desarrolladores, paridad multiplataforma y velocidad de desarrollo a menudo pesan más que los costos de RAM/CPU; las empresas optimizan para la velocidad y la viabilidad.
- Lado anti-Electron: derrochador, traslada los costos de hardware/energía a los usuarios, especialmente perjudicial para apps que están siempre en ejecución (chat, música).
- Algunos sostienen que los usuarios en su mayoría carecen de mejores opciones o de comprensión, no de que no les importe.
Proceso, refactorización y riesgo
- Varios abogan por ciclos explícitos: prototipar, luego “hacerlo bien”, luego “hacerlo mejor”, a veces con una regla deliberada de “tirar el primer borrador”.
- Otros advierten que, sin tiempo, autoridad y cultura para refactorizar, los pasos 2 y 3 nunca ocurren.
- Se mencionan conceptos como decisiones reversibles frente a irreversibles y el “último momento responsable” como herramientas para decidir cuándo invertir en “hacerlo bien” frente a “simplemente sacarlo”.