Idea principal

Un desarrollador que retoma un defecto que él mismo introdujo no solo repara. Es la única persona en posición de comparar lo que creía entregar con lo que realmente ocurrió. Ve dónde su comprensión de la necesidad era incompleta, si la prueba que habría atrapado el caso no existía, si la especificación dejaba la ambigüedad que él resolvió por su cuenta, si la arquitectura hacía probable el error.

Otro desarrollador que corrige en su lugar encuentra la causa técnica, no la causa de la decisión. Repara el síntoma sin que la información vuelva al lugar donde habría cambiado algo.

Es este bucle —entregar, encontrarse con la consecuencia, reconocer lo que faltaba— lo que produce la mejora. No es un efecto secundario de la corrección: es su valor principal.

Por qué es importante

Esto da un criterio de diseño a las políticas de calidad: una política que optimiza el plazo de corrección sin preguntarse quién corrige compra rapidez suprimiendo el aprendizaje.

Explica también la repetición de los mismos errores de diseño en un equipo. No vienen de una falta de competencia sino de un circuito de información que nunca vuelve al autor.

Matices y límites

El bucle solo se cierra si el defecto se vincula a su causa, y no solo a su línea de código: corregir sin nombrar lo que faltó aguas arriba produce una reparación más.

Y tiene un plazo: cuanto más tarde aparece el defecto, menos recuerda el autor lo que creía hacer en el momento de entregar.

Preguntas abiertas

• ¿Dónde consignar lo que la corrección revela —prueba que falta, especificación ambigua, arquitectura frágil— para que actúe sobre la entrega siguiente en lugar de quedarse en la cabeza de quien corrigió?