Idea principal

Se habla a menudo de las buenas prácticas del software como de un stock estable: bastaría con documentarlas, depositarlas en el archivo de directrices de un asistente de desarrollo y pedirle que las aplique.

Su historia dice otra cosa. Los design patterns clásicos respondían a un mundo de software determinado; la nube, los sistemas distribuidos, lo asíncrono, los microservicios y las arquitecturas de eventos hicieron aparecer otro, y hubo que inventar la idempotencia, los reintentos, los circuit breakers, las sagas, la observabilidad, la resiliencia distribuida. Ninguna de esas prácticas salió de una relectura de las anteriores: nacieron de sistemas reales, de averías, de migraciones difíciles, de restricciones de explotación y de compromisos dolorosos.

Para inventar una buena práctica no basta, por tanto, con conocer las antiguas. Hay que percibir por qué ya no bastan, lo que supone haber estado expuesto a un terreno que se resiste, y saber distinguir el momento en que un patrón es una respuesta elegante de aquel en que no es más que complejidad inútil.

Por qué es importante

Esto separa dos capacidades que se confunden en cuanto una herramienta sabe recitar el catálogo: aplicar una práctica y producir una nueva. Un asistente que compara soluciones, detecta recurrencias y documenta prácticas emergentes ayuda en la primera; nada establece que cubra la segunda antes de que el terreno haya hecho legible la necesidad.

También cuantifica un coste invisible para un equipo que ya no se enfrenta directamente a la explotación: hereda los patrones existentes y pierde el mecanismo que permitía inventar otros, una pérdida que solo se constata en la siguiente generación tecnológica.

Matices y límites

El terreno no tiene por qué vivirse en primera persona para instruir: un post-mortem serio, una traza de explotación, el incidente público de otra empresa transportan una parte de la resistencia. Lo que transmiten con seguridad es el patrón ya encontrado; su capacidad de hacer emerger el siguiente está por demostrar.

Y no toda resistencia produce una práctica: muchos incidentes solo dejan una corrección local, porque nadie se tomó el tiempo de extraer de ellos una regla.

Preguntas abiertas

• ¿Qué hace, en una avería, que engendre una práctica reutilizable en lugar de una corrección olvidada al mes siguiente?