¿Cómo me pueden pagar por reducir la deuda técnica?

Actualmente estoy trabajando para una pequeña empresa que tiene pocos productos técnicamente complicados. Soy el único desarrollador para uno de ellos. Hace aproximadamente un año, obtuve la versión heredada del producto y comencé a "apoyarlo".

El cliente solo habla de nuevas características, valor comercial y otros de ese tipo. El problema es que, aunque el código está en C #, es bastante procesal. No hay abstracciones, las clases solo se usan donde Visual Studio las requiere, por ejemplo, formularios. Las implementaciones de estas clases son realmente horribles y el código es realmente difícil de mantener.

Durante todo este año paso mi propio tiempo para refactorizar. En la última versión, hay bonitas abstracciones y cosas así. Tuve que volver a implementar una serie de componentes desde cero y realmente siento que agregar nuevas funciones o cambiar el comportamiento de estos componentes es MUCHO más fácil que para otros.

El problema es que paso mi propio tiempo. Realmente me gustan los resultados, pero no me gusta trabajar 12 horas por día. ¿Alguna vez has estado en una situación similar? ¿Qué debería probar? Ya he intentado discutirlo, pero aún no he tenido éxito.

Solo tengo miedo del momento en que decidimos implementar la nueva característica que requiere muchos cambios en el código heredado. Eso podría ser impactante para el cliente: ¿por qué necesita 8 horas para cambiar estos íconos? Al cliente simplemente no le importa que haya 500 lugares en el código que necesito cambiar. Y también debería encontrar primero estos 500 lugares.

¿Algunas ideas?

Paso 1: Deje de trabajar horas extras no pagadas.

Ya ha entrenado a su cliente y gerente durante un año para creer que la tasa actual de desarrollo es lo que debería esperarse. Esta es parte de la razón por la cual no entienden por qué una cosa "simple" podría tomar todo un día. No es necesario mantenerlos como rehenes e intentar dañar el proyecto. Pero debe explicar que sus expectativas son demasiado altas y que necesita otro desarrollador o más tiempo antes de la fecha límite. Asegúrese de mencionar específicamente a su gerente que ha estado trabajando horas extras no remuneradas y que planea no hacerlo tanto. Incluso si lo reduce a días de 9 horas, se notará la diferencia. Si su gerente le pregunta por qué no está haciendo su trabajo, puede señalar el hecho de que hizo un punto para advertirle que este sería el caso.

Paso 2: toma notas

El hecho de que no tenga tiempo para hacer el trabajo no significa que no pueda hacerlo más fácil cuando el trabajo se realiza (con suerte). Mantenga un registro de las ideas que tiene para arreglar el código y créelo en las reuniones para que otros conozcan sus preocupaciones. Eventualmente, llegará a un parche lento o la gente comenzará a comprender que sus preocupaciones tienen valor. Cuando llegue este momento, ya tendrá algunas ideas básicas sobre qué hacer en lugar de quedarse seco porque no ha mirado una sección de código en mucho tiempo.

... el código es realmente difícil de mantener.

Este es tu camino con la administración. Demuestre que el costo de "simplemente" corregir los errores y agregar nuevas funcionalidades es mayor que el de refactorizar y reescribir el código.

Por ejemplo, si con el código actual una nueva característica tomaría 2 semanas en agregarse y luego una cantidad significativa de tiempo para mantenerse (por ejemplo, 1 día a la semana), demuestre que con una refactorización de una semana puede realizar el desarrollo en 1 1/2 semanas pero que reducirá el mantenimiento a 1 día al mes (o menos). Estos números mostrarán que lo que está haciendo es rentable a mediano y largo plazo, aunque haya un costo a corto plazo.

Si bien es posible que a la compañía no le guste gastar el dinero ahora, verán que los beneficios potenciales son mucho mayores, es decir, será más productivo generando más código en menos tiempo y ese código será de mejor calidad.

Aplique la regla de Boy Scout : deje el código un poco más ordenado (es decir, con menos deudas técnicas) cada vez que lo toque.

Dé tiempo para hacer esto en todas las estimaciones que haga. Luego, mágicamente, con el tiempo la deuda técnica desaparecerá y se le habrá pagado por hacerlo.

Este enfoque es mucho más fácil que tratar explícitamente de ganar tiempo (y, por lo tanto, convencer a los clientes / gerentes de que paguen) por la deuda técnica. Le da una sensación mucho mayor de profesionalismo y un "trabajo bien hecho". Y finalmente, sus clientes y gerentes lo agradecerán a largo plazo, incluso si no entienden cómo sucedió .....

Esta es más o menos la triste realidad de la programación de mantenimiento. Está atascado con lo que le asignan mantener y si la persona que paga las facturas no quiere pagar lo que considera cambios sin beneficio, entonces esos cambios tienden a no hacerse.

Si desea justificar la obtención de estos cambios, mantenga un registro de todos los lugares que tiene que cambiar, incluso para la actualización más simple. Después de algunos cambios, discuta ese registro con su gerente. Si puede documentarlo, existe la posibilidad (aunque muy delgada) de que la persona con las cadenas del bolso se dé cuenta de que en realidad es más barato a largo plazo limpiar el código ahora, ya que hará que los futuros cambios sean más baratos.

Sus posibilidades de vender este aumento aumentan cuanto más tiempo se espera que este producto esté en uso. Las probabilidades también aumentan si una falla en el producto puede causar un problema de relaciones públicas para el cliente o costarle dinero.

Salvo eso, aprenda lo que pueda y pase a otra posición con menos mantenimiento.

Debe mostrar a su gerencia cómo la refactorización y la mejora del producto beneficiarán a la empresa.

Es probable que al cliente no le importe si el código es hermoso o feo mientras funcione, y la gerencia no estará ansiosa por explicarle al cliente que lo que ya pagó estaba mal diseñado y mal implementado. Al mismo tiempo, la gerencia no estará ansiosa por consumir el costo del tiempo de desarrollo que no mejora el producto de alguna manera visible (facturable).

Entonces ... tiene que convencer a la gerencia de que los cambios que propone ayudarán a la empresa:

• Muéstreles que una mejor arquitectura le permitirá agregar nuevas características más rápidamente.
• Explique que al continuar por el camino actual se pintarán en una esquina.
• Dé ejemplos de cambios que son muy caros de realizar en el sistema actual, pero que serían simples y baratos con un mejor diseño.
• Realice un seguimiento del tiempo dedicado a mantener el código heredado en lugar de agregar funciones vendibles. - Ayúdelos a explicar a los clientes existentes y futuros que, si bien el sistema existente era bastante bueno, la arquitectura nueva y modernizada permitirá muchas mejoras nuevas, una mayor confiabilidad, etc.
• Mitigue el riesgo asociado con los cambios que propone. Los gerentes son reacios al riesgo, y los cambios radicales en un sistema existente parecen inherentemente riesgosos.
  • Priorice la modernización de los diversos componentes de acuerdo con el costo y el beneficio, y asegúrese de que la administración esté de acuerdo con sus prioridades.
  • Utilice las pruebas unitarias para ayudar a garantizar que los componentes modernizados sean compatibles con el código heredado restante.
• Siga el progreso del esfuerzo de modernización. Muestre beneficios tan pronto como sea razonablemente posible, pero recuerde a todas las partes que hay más trabajo por hacer.

Puede que no te des cuenta, pero Johnny Cash predijo el movimiento de refactorización y escribió una canción sobre la mejor manera de refactorizar una gran base de código existente.

Por supuesto, tuvo que envolverlo en una metáfora automotriz para que su audiencia pudiera identificarlo.

"Una pieza a la vez" - Johnny Cash

Parece que podría cobrarle al cliente por el tiempo que el cambio "debería" tomarse y aún así salir MUY por delante a largo plazo.

Si le gusta limpiar el código (y parece que lo hace al menos un poco), continúe haciéndolo, pero no se agote. Eso no le hace ningún bien a usted, a su empresa ni a sus otros clientes.

Asegúrese de que su gerencia y cualquier persona que trabaje con el cliente sepa que el código no está en la mejor forma para que puedan tomar una decisión informada, solo porque usted posee ese código no significa que deba tomar las decisiones comerciales al respecto, Si no son conscientes de los problemas con el código, no pueden hacer su trabajo.

Aunque la aplicación del cliente tiene algunas deudas técnicas, no lo olvide, probablemente se les cobró un pequeño descuento. Es posible que no se hayan dado cuenta de esto, pero eso es lo que sucede cuando toma la oferta más baja.

Deben decidir si desean pagar el precio total de los cambios en las funciones o prescindir de ellos. Es su elección. Puede dejar que tomen la decisión o seguir trabajando de forma gratuita. Puede intentar mencionar el trabajo de limpieza que realizó y ofrecer un pequeño descuento por el trabajo realizado. De nuevo, es su elección.

La forma en que abordaría esto es comenzar explicando el concepto de deuda técnica a sus jefes para asegurarse de que lo obtengan. Abórdelo desde un punto de vista económico, perspectiva empresarial. Cada vez que solicitan una nueva función, la deuda técnica acumulada en el producto afecta su eficiencia y, por lo tanto, cada función cuesta un poco más debido a esta deuda.

Una vez que entiendan de lo que está hablando, trate de negociar un poco de su tiempo para reducir la deuda técnica. En mi empresa, hemos tenido un éxito razonable al solicitar el 10% del tiempo de cada desarrollador para trabajar en la reducción técnica de la deuda.

Una vez que tenga algo de tiempo para trabajar en esto, asegúrese de usarlo realmente (y no solo trabaje 10% de tiempo extra para hacerlo, manténgase en sus armas). Cree un catálogo de ítems de deuda técnica y priorícelos y comience a dividirlos. Tienes que comer el elefante un bocado a la vez.

Y no olvide tener en cuenta mejores herramientas. Resharper es una gran herramienta de refactorización que se conecta a Visual Studio.