Idea principal

"Quien crea el bug lo corrige" se lee espontáneamente como una regla de tratamiento: diría quién hace el trabajo de corrección. Su efecto principal se sitúa, sin embargo, antes de la corrección.

Un desarrollador que sabe que sus defectos le volverán directamente entrega de otra manera. Prueba más, revisa mejor, empuja con menos ganas un cambio frágil para cumplir una fecha, acepta con menos facilidad programar sobre una ambigüedad fuerte. La regla es un incentivo antes que una asignación.

No garantiza nada: un desarrollador concienzudo puede producir un defecto, y una regla de asignación no sustituye a un sistema de producción. Lo que cambia es el arbitraje privado que cada uno hace en el momento de entregar, cuando nadie mira.

Por qué es importante

Esto responde a la objeción del coste: aplicar la regla altera la planificación, ralentiza la funcionalidad siguiente, trae de vuelta a alguien a un tema que había dejado. Ese coste es real, pero se compara con el flujo de defectos que reduce, no solo con el tiempo de corrección que desplaza.

Explica también por qué las excepciones salen caras: cada excepción no solo desplaza una corrección, debilita el incentivo para todas las entregas futuras.

Matices y límites

El incentivo supone que el desarrollador haya tenido control sobre lo que entregaba. Obligado por un plazo impuesto o por una especificación que se le prohibió discutir, sufre la regla sin poder responder a ella, y esta se convierte en una sanción.

Tampoco dice nada de los defectos surgidos del legacy o de varias contribuciones, donde el autor no es identificable.

Preguntas abiertas

• ¿A partir de qué plazo entre la entrega y la aparición del defecto deja el incentivo de operar sobre la manera de entregar?