He encontrado este escrito traducido de Eric S. Raymond, que me ha encantado.

El artículo se lee muy bien, es muy ameno pese al tema del que trata y cuando se escribió (hace mas de 10 años), y cuenta el desarrollo de un proyecto de software desde su concepción, sacando algunas conclusiones durante el camino a las que irónicamente estoy llegando yo también en las últimas semanas 😀

Hay que leerse el artículo, pero copio aquí las lecciones con las que estoy más de acuerdo:

2. Los buenos programadores saben qué escribir. Los mejores, que reescribir (y reutilizar).
3. Contemple desecharlo; de todos modos tendrá que hacerlo.
   Este me encanta, estoy en pleno proceso de «borrón y cuenta nueva».
   […] no se entiende cabalmente un problema hasta que se implementa la primera solución. La siguiente vez quizás uno ya sepa lo suficiente para solucionarlo. Así que si quieres resolverlo, disponte a empezar de nuevo al menos una vez.
5. Cuando se pierde el interés en un programa, el último deber es heredarlo a un sucesor competente.
   Que gráaandeeee (y utópico)
7. Libere rápido y a menudo, y escuche a sus clientes.
   Pruebas, pruebas y mas pruebas. Con datos reales y desde el primer día. Es la única manera de que no haya sorpresas al final.
   Lo que lleva de cabeza a la 8:
8. con muchas miradas, todos los errores saltarán a la vista.
   […] más usuarios detectan una mayor cantidad de errores.
11. Lo más grande, después de tener buenas ideas, es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor.
    Siempre hay que pensar en el usuario. Si no, ¿para qué estamos haciendo un programa?.
12. Frecuentemente, las soluciones más innovadoras y espectaculares provienen de comprender que la concepción del problema era errónea.
    Cuando usted se topa con un muro durante el desarrollo […] es, a menudo, la hora de preguntarse no si usted realmente tiene la respuesta correcta, sino si se está planteando la pregunta correcta. Quizás el problema requiere ser replanteado.
    Y volvéeemos a la 3 😉
13. La perfección (en diseño) se alcanza no cuando ya no hay nada que agregar, sino cuando ya no hay algo que quitar.
    Cuando el código va mejorando y se va simplificando, es cuando sabe que está en lo correcto.
    Cuando tengo archivos de clase muuuy largos o excesivamente cortos, me pregunto si lo estaré planteando bien.
14. Toda herramienta es útil empleándose de la forma prevista, pero una *gran* herramienta es la que se presta a ser utilizada de la manera menos esperada.
    Tengo algunos componentes que de lo flexibles que son, me encuentro utilizandolos para cualquier cosa que no pensé que sirvieran.