Cómo medir el valor potencial de la refactorización

En un proyecto antiguo y grande con deuda técnica, ¿cómo puede estimar o medir de manera confiable el beneficio de refactorizar el código?

Por ejemplo, supongamos que tiene algunos componentes dentro de una solución de pila de software escritos en un idioma anterior, y algunos componentes posteriores escritos en un idioma más nuevo. Un equipo de desarrollo agrega constantemente nuevas funciones y correcciones de errores a esta solución.

Los desarrolladores sugieren que reemplazar los componentes del lenguaje antiguo existente con la nueva versión sería 'algo bueno'. Sin embargo, este trabajo no agregará características adicionales y costará x días de desarrollo.

Un vendedor sugiere agregar 'una gran característica nueva'. La compañía mide el valor de su sugerencia utilizando una fórmula. es decir. Ganará a la compañía F millones de libras, durante t años a un costo de x días de trabajo dev

¿Cómo puede la empresa costar la propuesta de refactorización de manera significativa? ¿Y bajo qué circunstancias es probable que sea la opción más rentable para la empresa?

Ganará a la compañía F millones de libras, durante t años a un costo de x días de trabajo dev

Lo que ignora los costos de mantenimiento, los costos de soporte, el costo de ventas / marketing y hace una gran cantidad de suposiciones sobre cómo se tomará la característica en el mercado.

Pero lo que sea; su pregunta es lo suficientemente clara sobre lo que está buscando:

¿Cómo puedo hacer un caso de negocios para refactorizar?

Lo principal a tener en cuenta es que el tiempo es igual al dinero. Puede ir directamente a "5 desarrolladores 2 semanas = 80 horas * 5 desarrolladores * $ 50 / hora -> $ 20,000" y eso tiene sentido para la gente de negocios. Los empresarios inteligentes notarán que a esos 5 desarrolladores se les paga de cualquier manera, con lo que usted responde que no está gastando / ahorrando los $ 20,000, sino que está utilizando los $ 20,000 de la manera más rentable. De todos modos, con la lista.

• Eficiencia : presumiblemente, puede hacer más cosas con C # que con VB6. Mejores herramientas, mejores bibliotecas, lo que sea. Las tecnologías más nuevas tienden a ser mejores en las cosas que las más antiguas. Si puede hacer cosas en menos tiempo, eso significa que está ahorrando dinero a la empresa.
• Gastos generales : la codificación no es el único costo del software. Considere lo que sucede cuando sale Windows 2020. ¿Cuánto tiempo y esfuerzo vas a dedicar a que esa aplicación VB6 funcione en ella? ¿Cuánto más tiempo y esfuerzo es eso que una aplicación C #? Eso está ahorrando dinero a su empresa.
• Calidad : presumiblemente, puede hacer cosas con mayor calidad en C # que VB6 (o con una arquitectura más limpia, o cualquier otra cosa que sea su objetivo de refactorización). Mayor calidad significa menos errores. Menos errores significa menos costo para corregir esos errores, menos costos de atención al cliente para resolver esos problemas, menos pérdida de clientes debido a problemas de calidad, mayores ventas debido a una reputación de calidad ... todos los dólares para su empresa.
• Ahorro de recursos humanos : seamos realistas: nadie quiere trabajar con esa aplicación VB6 de mierda. Eso significa que más personas dejarán la compañía y gastarán tiempo y dinero para reemplazarlos. Eso significa que lleva más tiempo y dinero contratar nuevos empleados. Lo peor de todo, significa que tendrás desarrolladores que están totalmente bien cometiendo suicidio profesional trabajando con esa aplicación VB6. Esos desarrolladores a su vez aceleran la espiral de muerte de los problemas de calidad. Reducir la rotación y los tiempos de contratación ahorra dinero a su empresa. Mantener alejados a los desarrolladores complacientes y malos salva a su empresa.
• Moral : de manera similar, los programadores que ya están allí odian trabajar en VB6. Lo harán, e incluso podrían hacerlo bien. Pero apesta. Quizás no para todos, pero ciertamente para algunos. Eso significa más tiempo dedicado a navegar por la web para recuperar la motivación. Significa almuerzos más largos. Significa menos hacer las cosas mientras los programadores tardan más en recuperarse del trabajo sucio.
• Capacidad : esto es menos aplicable con los refactores basados ​​en tecnología, pero se aplica a los refactores de arquitectura. Ciertos problemas de código le impiden activamente proporcionar una característica genial X para ganar toneladas de dinero. Quizás no puedas escalar. Tal vez no pueda acceder a los datos para hacer una buena informática. Tal vez el código es un nido de ratas que es prohibitivamente difícil hacer el trabajo. Lo que sea. A veces estás en ese punto, a veces estás conduciendo directamente hacia ese punto. Es difícil traducirlo al habla comercial, pero si puede, "este problema nos impide aprovechar las oportunidades X, Y y Z" puede ser poderoso.

Con todo, todo se reduce a "estas cosas nos ayudarán a hacer mejor nuestro trabajo; si lo hacemos mejor, podemos ganarle / ahorrarle más dinero".

La pregunta que debe hacerse es cómo sabe el vendedor que la función le costará x días de trabajo al desarrollador. Dado que incluso los buenos gerentes de proyecto con años de experiencia profesional a menudo no pueden decir eso, esos datos provenientes de un vendedor parecen extremadamente ... especulativos .

Según mi experiencia, los vendedores generalmente no hacen estimaciones, pero adivinan cuánto es demasiado para la gerencia o el cliente: si la gerencia está lista para pagar 50 semanas hombre de trabajo, pero rechazará absolutamente 75 semanas hombre, digamos que la función tomará 70 semanas hombre mientras está listo para renegociar (algo que está fuera de discusión para una estimación real) hasta 55 semanas hombre.

• Por un lado, tiene estimaciones hechas por expertos en TI que dicen algo como:

  De acuerdo con esta auditoría específica, estamos desperdiciando $ 8 000 por día usando una tecnología obsoleta en comparación con proyectos similares de tamaño similar que usan tecnologías más nuevas. También parece que llevará de 50 a 80 semanas hombre para migrar todo el código base; durante este tiempo, no habría nuevas características lanzadas. También existe un riesgo del 10% de que la migración de un componente específico pueda generar entre 20 y 30 semanas de trabajo adicionales.

• Por otro lado, tiene conjeturas hechas por vendedores, en función de su influencia al negociar con la persona que necesitan convencer.

Se trata de cuán influyente eres en tu empresa. La comunicación es clave aquí, y aquí es donde los vendedores suelen ganarse a los profesionales de TI cuando se trata de explicar los beneficios de una función a la administración (o al cliente).

Tenga en cuenta que si en el pasado, sus estimaciones eran bastante precisas, ganará reputación e influencia. Si sus estimaciones siempre fueron incorrectas, la gerencia probablemente ignoraría sus propuestas.

En cuanto a las estimaciones, es extremadamente difícil hacer uno valioso aquí, ya que hay una gran cantidad de parámetros a tener en cuenta. Entre otros:

• ¿Realmente sabes cuán hábil es tu equipo en C # en comparación con VB6? ¿Se basa en mediciones reales o simplemente en conjeturas?

• ¿Este equipo ha desarrollado grandes proyectos en C #? ¿Conocen las herramientas que deberían usar (IDE, depuradores, perfiladores, etc.)? ¿Necesita licencias adicionales (que, en el mundo de Microsoft, significan miles de dólares por máquina)?

• ¿El proyecto actual es totalmente claro y puede garantizar que no habrá sorpresas al migrar? ¿Es sencillo reescribir todo , cada característica, o habría sorpresas?

• ¿Tiene la infraestructura que admite C #? ¿Qué pasa con la integración continua? ¿Qué pasa con su servidor de compilación? Guías de estilo? Damas estáticas?

• En producción, ¿los servidores (si se trata de una aplicación web) o las PC del cliente (si se trata de una aplicación de escritorio) pueden ejecutar la versión de .NET Framework que espera utilizar?

Pero lo más importante es saber por qué quieres reescribir todo. ¿Cuál es el problema que estás tratando de resolver mediante una reescritura? ¿Una pérdida de productividad? ¿Como lo mides? ¿Cómo muestra esta pérdida de productividad a la gerencia?

Una vez que haya demostrado que está desperdiciando, digamos, $ 8 000 por día debido a VB6 (lo que significa que ahorrará $ 8 000 por día una vez que migre a C #), ¿cómo explica el beneficio de mantener cada desarrollo de nuevas características y centrándose en una reescritura completa? ¿Cuál es el beneficio en comparación con la reescritura progresiva donde migras tus componentes en pequeños trozos uno por uno, mientras envías nuevas funciones?

En primer lugar, debe estimar el costo de desarrollo para la refactorización como lo haría con la solicitud de función impulsada por las ventas.

Esto puede ser difícil de obtener con precisión si se trata de un trabajo grande, pero, suponiendo que tenga personas con suficiente experiencia en las 2 tecnologías, debería ser factible.

En segundo lugar, necesita una estimación del costo de no refactorizar. Si estuviera haciendo las estimaciones para mí, esperaría algún nivel de métricas. Por ejemplo, la diferencia entre el costo de desarrollo promedio para el código VB y para el código C # durante una cuarta parte. O algo así. Obviamente dependerá de la precisión con la que haga un seguimiento de esto.

Con estos 2 números, puede estimar el período de recuperación de la inversión que le dará la refactorización, es decir, en qué punto la refactorización pasará de un costo neto a una ganancia neta.

Solo puedo adivinar cuán persuasivo sería cualquier resultado dado. Sin embargo, si es menos de un año, probablemente será bastante fuerte, mucho más de 2 años, entonces es muy posible que tenga dificultades.

Además, probablemente valga la pena agregar otras dimensiones para ayudar a construir su caso. Uno que he usado en el pasado es ver si alguna entrevista de salida citó la tecnología como un motor. Si es así, puede argumentar que la refactorización retendrá al personal (la contratación y la capacitación son muy caras).

Obviamente, puede argumentar estas cosas sin evidencia de apoyo, pero creo que puede hacer una gran diferencia en el impacto del caso.

El valor de la refactorización surge de múltiples maneras diferentes.

Le ayuda a realizar otros cambios más adelante, por lo que los X días que le habría tomado a esa característica ahora tardarían 2 / 3X días en completarse. Para usar la terminología ágil, aumenta la velocidad.

El cambio explícito en la lista ayudaría con el tiempo, ya que ya no necesitaría mantener desarrolladores con experiencia VB6, solo aquellos con experiencia C #.

También ayuda de otras maneras menos tangibles, como la retención y contratación de personal. ¿Un trabajo con C # y VB6 sería más o menos atractivo que un trabajo con solo C #? ¿Sería más o menos probable que tome un trabajo o permanezca en un trabajo trabajando en una buena base de código o una pésima?

Creo que el punto que otras respuestas pierden es que necesita medir el costo de refactorizar contra los ingresos perdidos por no refactorizar.

Refactorizar por cambiar el código es una pérdida de tiempo. Necesita aportar valor a la mesa. En este contexto, no me refiero a pasar una hora refactorizando una clase problemática, sino a la refactorización principal, como cambiar a un lenguaje CLR diferente como el que usó en su ejemplo.

• Si seguimos haciendo lo que estamos haciendo, ¿nos estamos perdiendo algo? ¿Existe un diseño antiguo y crujiente que nos impide obtener valor? Por ejemplo, si queremos agregar una característica, ¿es tan difícil que podría tomar, por ejemplo, 100 horas para implementar, frente a 50 horas para refactorizar y 25 horas para implementar contra el nuevo diseño?

• ¿El código existente conlleva una deuda técnica que nos está costando dinero? ¿Es este viejo código horrible la fuente de errores? ¿Terminamos trabajando gratis para solucionar problemas por eso? A nadie le gusta regalar lucrativas horas facturables de forma gratuita.

• ¿Es el costo de refactorización igual o menor que el costo de no refactorizar?

• ¿Es posible amortizar el costo haciendo que un pequeño equipo de estrellas de rock refactorice el código que causa la mayoría de los problemas? ¿Podemos distribuir el refactorizador entre lanzamientos? Hay pequeñas ineficiencias en todas partes: ¿podemos "llenar los vacíos" por así decirlo con este trabajo extra?

Beneficios de tener un sistema refactorizado

Usted presenta una justificación comercial para la refactorización al comparar los beneficios finales de la empresa entre hacerlo y no hacerlo. Significa una reducción de los costos reales actuales o un aumento en la entrada de efectivo real futuro.

Las principales partidas presupuestarias afectadas por la refactorización son las siguientes:

• Costos de mantenimiento: si el sistema actual es una pila frágil de espagueti y se puede observar en la práctica que la reparación de pequeños errores (tanto en desarrollo como en operaciones) requiere una gran cantidad de horas-hombre, entonces podría esperarse que los costos de tales el mantenimiento será menor para un sistema "correctamente rediseñado". Eche un vistazo a cuáles son sus costos anuales de mantenimiento puro y cómo podrían cambiar de manera realista después de la reescritura.

• Costo de agregar nuevas funciones: una vez más, si el diseño y la estructura del sistema actual hacen que sea excesivamente lento escribir nuevas funciones, entonces una reescritura podría proporcionar ahorros. Eche un vistazo a su presupuesto planificado para nuevas funciones, pero sea realista: si afirma que verá una mejora del 50%, entonces espere desarrollar funciones en x meses-hombre que antes tardaron 2 * x meses-hombre en darse cuenta; tales promesas pueden ser difíciles de cumplir.

• Impacto en la calidad del software en las ventas: si el sistema actual con frecuencia causa problemas visibles para el cliente, por ejemplo, fallas o tiempo de inactividad a pesar del esfuerzo de mantenimiento adecuado, una reescritura puede ser una solución. Si este es un problema importante, los mismos vendedores pueden cuantificar el valor de una "característica" llamada "producto más estable".

Si los tres puntos anteriores no alcanzan el costo esperado de reescritura (y más; el costo de oportunidad de gastar x días de desarrollo en no características es igual al valor de esas características, que es mayor que el costo puro de x desarrollo días), entonces me temo que eso es todo: los ahorros esperados no justifican la reescritura.

Además, si su hoja de ruta no muestra la necesidad de nuevas funciones "tanto como pueda proporcionar", entonces los ahorros deben estar en una forma "solía llevar a 10 personas a hacer todo lo necesario, pero después de la reescritura, nosotros "Podré hacer lo mismo con solo 6 personas" . Si puede "vender" más proyectos de desarrollo que los que tiene, entonces mejorar la eficiencia le permite desarrollar más cosas, pero si el negocio con los recursos actuales ya puede desarrollar todas las cosas que aportan un valor adicional, entonces el único beneficio financiero puede provenir de pagar menos personas o tener personas más baratas.

El valor de la refactorización se puede medir de esta manera: actualmente, la nueva función x costará 5 desarrolladores 2 semanas. Si refactorizamos un componente antiguo, el costo de las nuevas funciones se reducirá en un 20% estimado. Por lo tanto, la nueva función x solo costará 4 desarrolladores durante 2 semanas.

La refactorización es una inversión para reducir el costo de desarrollos futuros. Si no puede hacer ese argumento para su refactorización, probablemente no exista un argumento comercial para ello.