Reparando un error que nunca ha causado un problema hasta ahora

Recientemente realicé un cambio que hizo que algunos códigos se ejecutaran con mucha más frecuencia de lo que solía hacerlo. Esto condujo al descubrimiento de un error. Este error tenía el potencial de ocurrir cada vez que se ejecutaba el código, pero debido a que se ejecutaba tan raramente, nunca apareció.

Cuando llamé la atención del desarrollador principal, quiso que deshaga el cambio que expuso el error en lugar de corregirlo citando el adagio: "Si no está roto, no lo arregles".

Está claro para mí que solo tuvimos suerte hasta ahora, pero él no escuchará la razón.

¿Debo arreglarlo de todos modos?

Actualizar

El líder técnicamente no tiene ninguna autoridad sobre mí. Solo tenencia. Ha sido el único desarrollador del proyecto durante varios años hasta hace un año y creo que no toma muy bien las críticas constructivas. Por lo que vale, no lo critiqué. Solo señalé que solo porque el error nunca apareció no significaba que no estaba allí.

Sugeriría que si tiene un seguimiento de errores, envíelo. Si es crítico, entonces elevarlo y llamar su atención. Deja que tu superior lo rebaje en el rastreador. Cuando las cosas van mal, tendrás el rastro de papel.

Personalmente lo arreglaría, a menos que requiriera una cantidad significativa de esfuerzo mayor de lo que valía la pena. "Si no está roto, no lo arregles" es horrible aplicarlo al software.

Si su desarrollador principal es su jefe y él dice que no lo toque, en ese caso no lo haría.

La mayoría de las respuestas y comentarios sugirieron mitigar la responsabilidad de la decisión al crear un informe de error y dejar que otra persona haga la llamada.

Como no tengo un rastreador de errores (y dudo que alguien más que yo lo use si lo tuviéramos) hice lo mejor. Repasé la cabeza del desarrollador principal. Después de explicar la situación a la gerencia, vieron las cosas a mi manera. Me dijeron que lo arreglara correctamente e ignorara la solicitud de demanda del cliente potencial. Dijeron que suavizarían las plumas con volantes si alguna vez descubría el subterfugio y se quejaba.

No es una solución ideal, pero al menos el error se solucionó correctamente.

Recuérdele que la frase es: "Si no está roto, no lo arregle" y no "Si el cliente no lo ha notado, no lo arregle".

¿Qué justificación tienes para el cambio que hiciste? Si no puede señalar qué cambios experimentaría el usuario o si se ha eliminado la deuda técnica, me pondría del lado del desarrollador principal en términos de decir que simplemente retroceda el cambio, ya que esto solo empeora las cosas.

Tienes al menos un par de opciones diferentes aquí en mi opinión:

Si simplemente continúa y corrige el error, corre el riesgo de agregar más errores a la mezcla que podrían ser contraproducentes para mi mente. Dependiendo de cuánta experiencia tenga y la confianza de evitar alguna sorpresa desagradable que probablemente sea mi guía aquí.

Si haces lo que se te dijo que hicieras, ¿es solo la culpa lo que sería el problema o es más que eso? Me pregunto qué está mal aquí aparte de las cosas conocidas como principios y valores. Lo digo como una broma, pero también como un punto honesto de lo que está mal con esta idea.

Si bien mi instinto abrumador sería corregir los errores y no ocultar el problema, hay situaciones en las que me tapaba la nariz y ocultaba el problema.

1. El código se usa internamente y ocasionalmente, por lo que las consecuencias del error son manejables dentro de la empresa.
2. Consideraciones comerciales abrumadoras que exigían el envío hoy, y una solución de error podría implementarse 2 semanas después con consecuencias mínimas.

Profesionalmente, no me gustan estas respuestas, y estaría dejando en claro internamente que estaban ocurriendo éter de estas situaciones.

En última instancia, no debe hacer nada que su superior le haya dicho explícitamente que no haga. Creo que lo mejor que puede hacer en su posición es crear un informe de errores en cualquier base de datos de seguimiento de errores que tenga. De esta manera, al menos, todos conocen el problema y alguien con más autoridad puede decidir qué hacer con él.

Copie la función con errores, aplique la corrección, cámbiele el nombre, tal vez disimule un poco y llame a eso en su lugar.

Según su comentario de dos errores de showtopper, su mejor opción puede ser seguir la letra de la ley, pero ignorar su espíritu.

Obviamente, hay una desventaja en la codificación de cortar y pegar, pero parece que ese será el menor de sus problemas.