Habrás oído la frase “better done than perfect”, que significa que es mejor hacer algo que no es perfecto que no hacer nada.

A mí me gusta más la frase “better done THEN perfect”, que significa que dejar de lado la perfección en favor de la ejecución conlleva la necesidad de mejorarlo luego.

Implica que la velocidad no está reñida con la mejora, sino que la requiere.

¿Qué significa “perfecto” en el contexto del software?

Porque este blog trata de software. No estoy hablando de mejorar la característica que hemos publicado, sino el código que hemos escrito para ello.

El concepto de “perfecto”, como los de “bueno” o “malo”, son relativos a un criterio de calidad.

Un código para ser perfecto debe cumplir con los criterios de calidad externos (UX) y con los criterios de calidad internos (DX).

(Si estamos haciendo una API incluso para consumo interno, el contrato es la UX para nuestro usuario, que es otro servicio. La DX se refiere al desarrollador que tiene que trabajar con el código, no al desarrollador que tiene que usar la API.)

En el momento en el que tenemos la UX, podemos desplegar, pero hasta que no tengamos la DX no debemos cerrar el ciclo de desarrollo.

Ejemplo de la cocina

Cuánto se tarda en hacer una tortilla:

• de setas y queso: 15 minutos.
• de espárragos: 20 minutos.
• de patata: 40 minutos.
• de merluza: 30 minutos.
• de camarón: 25 minutos.
• de coliflor y bacalao: 30 minutos.
• de verduras: 35 minutos.
• francesa de espinacas y aguacate: 20 minutos.
• francesa con gambas: 15 minutos.

¿Cuánto se tarda en hacer todas esas tortillas una tras otra? ¿ 15 + 20 + 40 + 30 + 25 + 30 + 35 + 20 + 15 = 220 minutos?

No, porque nos quedamos sin sartenes limpias. No solo eso, toda la cocina se vuelve un absoluto desastre que no nos permite hacer otra cosa que no sea limpiarla.

Curiosamente, jamás he visto una receta de cocina que incluya el tiempo necesario para limpiar y recoger después de terminar.

En desarrollo pasa igual: desplegar sin limpiar es cocinar sin fregar.

El Problema.

En el mundo del software, tenemos el concepto TTD (Time To Deploy), y tenemos la columna “done” en nuestros tableros de trabajo, a donde movemos las tarjetas cuando hemos desplegado, momento en el que nuestros queridos compañeros de producto (y no es irónico), esperan que podamos empezar a trabajar en el siguiente ticket.

Porque llevar los tickets a done es lo que aporta valor al negocio a corto plazo, por lo que mantiene la empresa funcionando.

Pero esas expectativas generan una presión que nos lleva a descuidar la DX; y la DX, porque es lo que asegura el negocio a largo plazo, porque es lo que nos permite seguir llevando más y más tickets a done.

Lamentablemente, en vez de aprender a comunicar de forma efectiva y productiva esta realidad, resolvemos el problema con subterfugios que dañan tanto al producto como al desarrollo.

Los Subterfugios.

Boy Scout Rule (mal entendida)

La Boy Scout Rule es un principio de desarrollo de software que dice que “siempre hay que dejar el campamento más limpio que como se encontraba”.

La regla del Boy Scout funciona cuando mejora lo que ya está bien. Pero terminamos arreglando cosas que no están bien, que quedaron mal tras tickets anteriores. Cuando usamos la regla para poder reparar lo que nunca debió cerrarse, solo sirve para ocultar el pago de la deuda técnica bajo la alfombra del siguiente ticket.

Perjudica desarrollo:, porque las PRs pierden foco y claridad; y porque QA pierde contexto. Perjudica producto:, porque reduce la velocidad de entrega y hacer más difícil las estimaciones. Nunca saben en qué ticket se van a comer la deuda técnica. Ni tan siquiera saben que se la han comido.

ODD (Obedience Driven Development) ¡Vivan las cadenas!

Otra forma de tratar de garantizar que ciertos criterios de DX se cumplen antes de cerrar un ticket es mover las reglas de la capa de la mente del desarrollador a la capa de lenguaje o del tooling. De esa forma, el desarrollador no puede saltarse las reglas para satisfacer el criterio de DX más rápido. Si no cumple las reglas, el código no funciona.

A priori puede parecer una buena idea, pero la diferencia principal entre la mente del desarrollador y el tooling, es que el tooling carece de contexto elevado.

Es la paradoja de la sobreingeniería normativa: reglas pensadas para proteger la mantenibilidad que, por exceso, la destruyen.

Cada restricción impuesta para proteger la mantenibilidad añade un requisito más, y el foco del desarrollador pasa de expresar intención a satisfacer reglas.

Dichas reglas tan fuertes como ciegas no preservan la mantenibilidad, ni añaden valor técnico.

El resultado es un sistema más difícil de leer, extender y razonar. Justo lo que se pretendía evitar.

Perjudica desarrollo: porque empeora la DX, y nos hace perder el tiempo escribiendo código que no aporta nada. Perjudica producto: porque reduce drásticamente la velocidad de entrega.

Consistencia Dogmática

No todas las reglas fuertes están en el tooling; algunas están en la cultura del equipo, bien de forma inconsciente, o bien de forma deliberada a través de patrones impuestos en nombre de la consistencia.

Sobre los consensos tácitos y emergentes, poco hay que decir. Basta tener la esperanza de que cuando cambie el contexto y no tengamos miedo a comunicar abiertamente las necesidades de cuidar la DX de nuestros tickets, los hábitos cambien y dejemos las prácticas defensivas.

Pero sobre los patrones impuestos, debo decir que cuando el proceso se impone al propósito, la arquitectura deja de ser una herramienta y se convierte en burocracia peor que inútil, dañina.

En nombre de la arquitectura one-size-fits-all, sacrificamos la capacidad de diseñar soluciones específicas para características concretas del problema.

Perjudica desarrollo: porque nos hace perder el tiempo escribiendo código que no aporta nada, y que es menos mantenible que el código que hubiéramos escrito si no hubiéramos sido forzados a seguir una arquitectura one-size-fits-all. Perjudica producto: porque reduce drásticamente la velocidad de entrega.

La Solución:

La solución es sencilla (aunque no fácil):

• Comunicar de forma efectiva y productiva la importancia de la DX
• Adaptar los flujos a “better done THEN perfect”.

better done THEN perfect

Solo tienes que añadir una columna “perfect” a la derecha de la columna “done” en tu tablero de trabajo.

Con ello:

• dejamos de forzar defensivamente criterios excesivos de DX en el “done” para protegerla ante la presión de entregar.
• visibilizamos la parte técnica de forma clara, transparente y correctamente priorizada.
• no acumulamos deuda técnica, sino que atajamos los problemas técnicos inmediatamente, cuando el contexto está caliente.

Conclusión

La perfección no alcanza con subterfugios o imposiciones: se cultiva con comunicación y alineación. Primero hecho, luego perfecto.