Un amigo decía que en un examen, donde la nota mínima de aprobación era 70 sobre 100, si el sacaba digamos 90 puntos, eso significaba que había perdido tiempo, ya que estudió más de lo necesario para aprobar. Ser suficientemente bueno pasaba a ser perfecto.
Si bien parece tonto, es un interesante punto de vista y lo vinculo con lo que hacemos al construir software. Si no ven la relación, pensemos en las siguientes preguntas:
- ¿Cuándo paramos de probar o cuándo paramos de corregir errores?
- ¿De qué sirve arreglar errores que no suman valor, que no tienen impacto en el negocio?
- ¿De qué sirve seguir buscando cómo optimizar el sistema para que soporte miles de usuarios concurrentes, si en producción solo tendremos menos de 500 usuarios al mismo tiempo?
- ¿Vale la pena perseguir la idea de construir un software perfecto? (cada tanto deberíamos volver a leer el libro Perfect Software and other illusions about testing de Jerry Weinberg).
Hay algo llamado “Knuth’s dictum” que dice “Premature optimization is the root of all evil” (que lo aprendí leyendo el libro Continuous Delivery de Jez Humble y David Farley). Básicamente, deberíamos posponer las optimizaciones hasta que sea claro que son necesarias, de manera responsable claro, atacando en orden descendente de importancia.
Es una interesante visión, el esfuerzo bien dedicado, el no trabajar de más, el saber parar a tiempo.
Creo que se trata de ser asertivo, para entender las necesidades, y cubrirlas, sin malgastar tiempo y esfuerzo en aspectos innecesarios.
De eso se trata!