Preferencia por el código desechable sobre los documentos de diseño

• Imaginamos que el desarrollo de software sigue un flujo limpio y ordenado

  • Se escriben documentos de diseño y se implementan funciones desplegando pequeños cambios mediante PR
  • El historial de Git se ve limpio y bien organizado
  • Pero la realidad es distinta

• La diferencia entre los documentos de diseño y la implementación real

  • Implementar un documento de diseño tal cual es una fantasía
  • Cuando empiezas a programar, terminas modificando el contenido del documento de diseño
  • Ningún plan sobrevive al contacto con el enemigo

• Nueva metodología de diseño: inmersión en el código

  • Se implementa un prototipo usando un PR en borrador
  • Se recibe retroalimentación desde temprano para ajustar el enfoque
  • Se documenta el PR en borrador como un registro histórico de ideas de diseño
  • Hay que estar preparado para desechar por completo el PR en borrador
  • A partir del PR en borrador, los PR avanzan gradualmente por etapas
  • Cada PR se prueba por etapas y se refuerza su solidez

• La importancia de la madurez

  • Es importante tener la capacidad de desechar las ideas que ya se programaron
  • Lo importante no es la cantidad de líneas de código, sino la transmisión del conocimiento organizacional
  • Hay que alinearse temprano en las partes importantes para que el trabajo de prototipado no se desperdicie

• Cómo usar los PR como documentación

  • Los PR son una de las mejores formas de documentación para los desarrolladores
  • Los PR son artefactos históricos que reflejan el estado en un momento específico
  • Los documentos de diseño a menudo ofrecen información distinta de la realidad

• La importancia de los prototipos

  • Un prototipo vale más que 1000 documentos de diseño
  • Para impulsar el cambio, hay que hacerlo con código y no con documentos
  • La organización debe ver los prototipos como una pregunta, no como una respuesta

• La utilidad de los documentos de diseño

  • Son útiles para organizar y archivar retroalimentación de distintos interesados
  • Son útiles cuando una idea es demasiado conceptual o de muy largo plazo
  • Son útiles cuando expresar una idea por escrito es más eficiente que programarla
  • Son útiles cuando la organización no tiene la disciplina para desechar la primera solución
  • Proporcionan un entorno donde el personal junior puede cuestionar con seguridad las ideas de desarrolladores senior

• El uso incorrecto de los documentos de diseño

  • Se usan para ralentizar el proceso de desarrolladores menos experimentados
  • Se usan como documentación, pero se vuelven obsoletos rápidamente
  • Intentan resolver todos los problemas de diseño, pero los problemas reales se descubren programando

• Si el equipo puede tener disciplina, hackear es mucho más eficiente que diseñar

  • Se recomienda crear esa disciplina dentro de la organización
  • Al final, el código tiene más fuerza que las palabras

[GN⁺]

Opinión de Hacker News

• El prototipado es una parte importante del proceso de diseño, y es necesario definir el problema y aclarar la solución.

  • A veces un documento simple es suficiente, pero otras veces se necesita mucho feedback e iteración.
  • Existe el dicho de que "unas semanas de código pueden ahorrar unas horas de planificación".

• Escribir es útil para explorar un problema, y hay quienes han pensado que entendían el problema, pero al escribir surgieron nuevas preguntas.

  • Esto recuerda el caso de un mentor que usó Lucidchart para explicar seis meses de trabajo.

• Hay experiencia usando soluciones temporales para terminar proyectos dentro del plazo.

  • Las soluciones temporales también se usan como herramientas de soporte en producción y sirven como ruta alternativa si se abandona la versión permanente.

• El mayor problema de los documentos de diseño es que nadie los lee.

  • El problema del prototipado es que la gente lo considera código final.
  • Se prefiere un enfoque híbrido: planificar y documentar a fondo, y escribir código prototipo con la calidad suficiente como para poder usarse en el producto final.

• Hay una gran diferencia entre el feedback sobre código y sobre diseño.

  • Los documentos de diseño impulsan la pregunta del "por qué" sobre el espacio del problema.
  • Cuando el prototipo funciona, se vuelve difícil plantear esas preguntas.

• Si la descripción del trabajo consiste en escribir mucho código para ver qué funciona, GPT puede reemplazar eso de forma más rápida y barata.

  • Lograr consenso sobre qué se debe construir siempre es un desafío.

• Casi nadie imagina que el desarrollo de software siga un flujo limpio y ordenado.

  • Escribir código se parece a escribir: el primer borrador siempre es malo y un buen texto requiere muchas revisiones.

• Hay casos en los que el código se apila como un Jenga y nadie quiere tocarlo.

• Se prefiere un proceso que documente las decisiones de diseño usando un hilo continuo de comentarios.

  • Este proceso se lleva con issues de GitHub.

• Se sigue reflexionando sobre este enfoque, y en el peor de los casos se puede perder mucho tiempo.

  • Escribir documentos de diseño ha sido más útil cuando se ha pensado lo suficiente el problema como para especificar las propiedades necesarias para una implementación correcta.
  • También ha sido exitoso implementar soluciones parciales e ir mejorándolas gradualmente.