“Reescribirlo correctamente significaría admitir que no puedo simplemente arreglarlo”

El parche como coartadaLlevas tres parches seguidos sobre el mismo módulo de facturación, otro try/catch envolviendo una función en la que nadie confía, y el pensamiento que te detiene no es 'esto necesita una reescritura'. Es que decir esa frase en voz alta significaría confesar que los parches nunca iban a aguantar. Así que sigues creyendo el mito: proponer una reescritura equivale a admitir que tú, personalmente, no pudiste simplemente arreglar lo que había, así que lo más seguro es un parche más.

Por qué la reescritura se siente como una confesiónEl mecanismo es el anclaje: en el momento en que heredaste este módulo, 'arreglarlo en su sitio' se convirtió en tu marco por defecto, y cada parche desde entonces ha reforzado ese marco como el único aceptable. Nombrar una reescritura ahora significaría salir del marco al que te ancliste el primer día, no porque el código lo contradiga, sino porque cambiar de marco se siente como revertir una decisión que nunca tomaste conscientemente.

La prueba del listado privadoAntes de tu próximo parche, dedica cinco minutos a una lista privada de dos columnas: una para las partes que podrías reparar genuinamente en su sitio, otra para las partes que solo describirías como 'necesita reescribirse'. Nadie la ve. Si la segunda columna se mantiene corta, el mito se sostiene por ahora. Si crece cada vez que la miras, eso es información que el próximo parche por sí solo no te va a dar.