- En una conversación reciente con un reconocido CEO tecnológico y un ingeniero, escuché una metodología interesante de desarrollo de software. Esta metodología me hizo pensar en otras heurísticas y generalizaciones.
Su método
- Al empezar el día, se pone a trabajar en una funcionalidad. Si no logra terminarla antes de que acabe el día, borra todo y vuelve a empezar al día siguiente. Las pruebas unitarias que escribió sí se pueden conservar.
- Si después de varios días todavía no logra implementar la funcionalidad, piensa en la base, la infraestructura o el refactor necesario para hacerla posible, implementa eso y luego vuelve a la funcionalidad.
- Este método es similar al movimiento de programación extrema de finales de los 90 y principios de los 2000.
Ideas sobre el método
"Escribe todo dos veces"
- Un consejo para ingenieros junior: resuelve el problema, guarda el código en una rama y luego vuelve a escribirlo.
- Descubrí este método por accidente después de que mi laptop se descompusiera. Reescribir tomó solo el 25% del tiempo de la implementación inicial y el resultado fue mucho mejor.
- Puedes obtener código con el doble de calidad en 1.25 veces el tiempo. Es útil para proyectos que requieren mantenimiento a largo plazo.
- El método de "volver a empezar cada día" es todavía más extremo. Cada vez que reescribes, terminas encontrando una solución más elegante.
"La cantidad tiene una cualidad propia"
- La cita de Stalin también aplica a los ingenieros de software. Para un ingeniero junior, sus primeras 100 mil líneas de código son indispensables.
- El método de "volver a empezar cada día" ayuda a escribir esas 100 mil líneas más rápido.
- Resolver el mismo problema repetidamente ayuda a recordar patrones.
- Con 5 mil líneas de código perfecto puedes ver todos los patrones principales. Las 95 mil líneas restantes reacomodan tus neuronas a través de la repetición.
Comparación con la heurística de "con una pistola en la cabeza"
- A la persona que propuso una solución para un problema, pregúntale: "Si tuvieras que terminarlo en 24 horas, ¿cómo lo harías?"
- Este método rompe los sesgos de encuadre y anclaje. A menudo puede inducir en pocos minutos un plan que se podría terminar en un día.
- En realidad no es un plan que de verdad pueda completarse en un día, pero la nueva solución muchas veces sí puede terminarse en unos pocos días.
- El objetivo de este experimento mental no es generar una solución real, sino establecer una cota inferior para la solución.
Búsqueda de rutas
- Lo clave es encontrar rutas dentro del espacio del problema. Cada ruta es una solución, y el rol del ingeniero es encontrar la mejor ruta.
- Vale la pena pensar en las similitudes entre estas heurísticas y los distintos algoritmos de búsqueda de rutas.
- Lo mismo ocurre con las heurísticas de ingeniería: convertirse en un mejor ingeniero significa encontrar mejores rutas dentro del espacio del problema.
Resumen de GN⁺
- Este texto explora metodologías y heurísticas eficientes para el desarrollo de software.
- El método de "volver a empezar cada día" y el de "escribir todo dos veces" son útiles para mejorar la calidad del código.
- La resolución repetitiva de problemas ayuda al reconocimiento de patrones y al reacomodo de neuronas.
- La heurística de "con una pistola en la cabeza" es útil para establecer una cota inferior para una solución.
- Encontrar la mejor ruta dentro del espacio del problema es el rol central del ingeniero.
5 comentarios
¿Están locos? Solo gente con muchísimo tiempo de sobra podría hacerlo; ¿de verdad creen que esto es algo realista?
En el entorno coreano de SI eso sería imposible... jaja, quizás solo en proyectos personales
Este enfoque es algo que jamás se me habría ocurrido.
Tengo que probarlo jaja
Coincido mucho con lo de reescribir.
Una vez borré por accidente el código en el que estaba trabajando y, al volver a escribirlo,
terminé haciéndolo considerando cosas que antes había ignorado por flojera de cambiar el diseño a mitad del proceso,
y el resultado fue incluso mejor.
Comentario en Hacker News
Es una buena estrategia escribir una función nueva dos veces. Pero para un desarrollador de negocio o un project manager, puede parecer una demora innecesaria
La pregunta de “¿y si tuviera que terminarlo en 24 horas?” es algo que un project manager no puede preguntar
El buen código se escribe eligiendo las abstracciones adecuadas
Si tienes colegas competentes, pueden mostrarte lo que se puede hacer en poco tiempo
Comparto la idea de que es bueno escribir el software dos veces
Si no puedes implementar una función incluso después de varios días, primero hay que hacer la infraestructura o la refactorización necesaria
“En 24 horas” y “escribir todo dos veces” están relacionados entre sí
Esta publicación es uno de los mejores “consejos de programación” que hay
A veces hace falta dejar corriendo un hilo en segundo plano para resolver un problema
El siguiente enfoque es útil