Calcular los costos del código incorrecto

Descubrí que si puedes proporcionar números válidos, es más probable que los gerentes actúen. (Si pueden entender la lógica y el costo / beneficio).

En mi humilde opinión, para hacer un caso convincente, necesitarías lo siguiente para mostrar lo malo que es:

• número de incidencias de soporte registradas para los problemas
• tiempo empleado en horas manteniendo / ayudando de banda el código incorrecto / haciendo soporte arreglos
• costo de tiempo basado en la tarifa por hora de las personas que realizan el mantenimiento / banda ayudas / soporte
• alguna manera de demostrar cuán críticos son estos elementos para la misión negocio

Y para justificar la refactorización, necesitarás:

• tiempo estimado para refactorizar e implementar cada uno de los 3 principales cosas malas
• costo estimado para la implementación (las mismas tarifas por hora que se usaron anteriormente)

Con estos, puede justificar el ahorro de tiempo si la refactorización toma mucho menos que el tiempo de soporte para 3 incidentes para cada uno de los 3 elementos principales. Puede argumentar que esta menor cantidad de tiempo invertido se

• ser menos que n más incidentes de soporte
• no habrá más de estos incidentes por estas cosas (¡YA MEJOR!)

Sin embargo, la parte más difícil de esta venta será responder a la siguiente pregunta, ya que muchas personas no asignan tiempo en el presupuesto para todo el apoyo que estás haciendo:

¿Cuánto tiempo más tendré que esperar a que termine el proyecto actual Y mientras está gastando tiempo trabajando en estos problemas con X ????? (a pesar de los tiempos de soporte actuales, que no se puede predecir y programar en los diagramas de Gantt)

Esto depende mucho de lo bien que se comunique con los tomadores de decisiones y de cómo entienden la situación.

DEFINITIVAMENTE, creo que vale la pena hacerlo, por lo que tiene la práctica de construir el caso con las métricas y ahorrarse tiempo, incluso si no lo hacen. Desafortunadamente, no todos son fáciles de convencer, a pesar de los datos. ¡BUENA SUERTE!

Tenga en cuenta que la refactorización también introduce errores (que se detectarán en sus pruebas, pero que, sin embargo, son errores y deben solucionarse). No tire de un Netscape por accidente. Depende de tu definición personal de "refactorización". Para algunos, esto significa "reescribir todo el código" para otros significa "cambiar algunos elementos internos". ¿Cómo sabes qué tipo de persona eres? Hágase la siguiente pregunta:

¿Estoy cambiando la interfaz pública?

Si la respuesta es sí, estás rediseñando. Si la respuesta es no, está haciendo refactorización y probablemente solo puede hacerlo a lo largo de sus actividades diarias sin una aprobación especial. Esto es relevante para su pregunta porque un rediseño generará muchos más errores, mientras que una refactorización suele ser más fácil de realizar (ya que sus pruebas ya ejercerán la interfaz pública y no deberán modificarse).

Es un caso difícil de hacer, porque nadie sabe cuánto costaría X con o sin el refactor que se hizo hace un año. En mi experiencia, los gerentes pragmáticos siempre rechazan este tipo de cosas porque:

1. El flujo de ingresos directos no proviene del esfuerzo (costo financiero, no facturable)
2. El código de trabajo feo sigue funcionando, corres el riesgo de crear problemas en lugar de solucionarlos (costo potencial de calidad)
3. Otros proyectos se retrasarán mientras usted refactoriza (costo de tiempo)

Todos estos números se basan, en última instancia, en suposiciones, en su caso comparando la cantidad que cree que costaría no a refactorizar, en comparación con lo que cree que costaría a refactor . Lo mejor que puedes hacer es demostrar que tienes algún tipo de base numérica y objetiva para las conjeturas y que tienes una muy buena.

Las ventajas son que probablemente será eficaz para convencerlos de que te dejen refactorizar, y podría ir bien y reducir la cantidad de errores.

Las desventajas son que si la cantidad de tiempo dedicado a corregir errores no se reduce al menos tanto como el tiempo empleado en refactorizar, probablemente no se le permitirá refactorizar más, y probablemente se lo culpe por " tiempo perdido.

Los ahorros en el tiempo de depuración que se obtienen al reducir la complejidad del proyecto en general, o al facilitar la adición de funciones, pueden ser muy difíciles de medir para ayudarlo mucho, pero podría mencionar que existen.