Calcular costos de código incorrecto

Estoy buscando argumentos para convencer a la gerencia de que invierta el esfuerzo en refactorizar.

Registramos el trabajo usando Jira y relacionamos cada svn-commit con una llamada de jira.

Mi idea es hacer lo siguiente:

• detectar manualmente un área de código que está extremadamente mal implementada, pero que se usa a menudo: tanto desde User-POV como desde Developer-POV (correcciones de errores)
• obtener los svn-commits que contienen los problemas JIRA
• filtrar los problemas de acuerdo con algunos criterios (tipo de problema, versión, prio., etc.)
• calcular el tiempo / esfuerzo dedicado a estos errores
• estimar esfuerzos y riesgos de refactorización
• presentar los números y pedir esfuerzo para arreglarlo.

¿Qué piensas de esto? ¿Sería útil y / o convincente tal medida? ¿Cuáles son los pros y los contras?

Descubrí que si puede 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ía lo siguiente para mostrar lo malo que es:

• cantidad de incidentes de soporte registrados para los problemas
• tiempo invertido en horas manteniendo / ayudando a un código incorrecto / haciendo arreglos de soporte
• costo de tiempo basado en la tarifa por hora de las personas que realizan el mantenimiento / curitas / soporte
• alguna forma de demostrar cuán críticos son estos artículos para la empresa

Y para justificar la refactorización, necesitará:

• tiempo estimado para refactorizar e implementar cada uno de los 3 principales de estas 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 requiere mucho menos tiempo de soporte para 3 incidentes para cada uno de esos 3 elementos principales. Puede argumentar que esta menor cantidad de tiempo invertido

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

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

¿Cuánto tiempo más tendré que esperar a que finalice el proyecto Y actual mientras pasas tiempo trabajando en estos problemas con X ????? (a pesar de los tiempos de asistencia actuales, que no se pueden predecir ni programar en los diagramas de Gantt)

Esto depende mucho de qué tan bien se comunique con los tomadores de decisiones y de cómo entiendan la situación.

DEFINITIVAMENTE creo que vale la pena hacerlo, así que tienen 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 detectará en sus pruebas, pero que, sin embargo, son errores y deben corregirse). No tire un Netscape por accidente. Depende de su definición personal de "refactorización". Para algunos, esto significa "reescribir todo el código" para otros, significa "cambiar algunas partes internas". ¿Cómo sabes de qué tipo 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á refactorizando y probablemente pueda 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 generalmente es más fácil de realizar (ya que sus pruebas ya ejercerán la interfaz pública y no necesitarán ser modificadas).

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 derriban este tipo de cosas porque:

1. Ninguna fuente de ingresos directos proviene del esfuerzo (costo financiero, no facturable)
2. El código de trabajo feo todavía funciona, corre el riesgo de crear problemas en lugar de solucionarlos (costo de calidad potencial)
3. Otros proyectos se retrasarán mientras refactoriza (costo de tiempo)

Todas estas cifras se basan en última instancia de conjeturas, en su caso, la comparación de la cantidad que supongo que costaría no refactorizar frente a lo que supongo que le costaría a refactorizar. Lo mejor que puede hacer es demostrar que tiene algún tipo de base numérica y objetiva para las conjeturas, y que tiene una muy buena.

Las ventajas son que probablemente sea efectivo para convencerlos de que le permitan refactorizar, y podría funcionar bien y reducir la cantidad de errores.

Las desventajas son que si la cantidad de tiempo dedicado a corregir errores no disminuye al menos tanto como el tiempo dedicado a la refactorización, probablemente ya no se le permitirá refactorizar, y probablemente se le culpe por el tiempo "perdido" .

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