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

16

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?

Andrey Agibalov
fuente
3
¿Cuál es tu pregunta? Si es un empleado, ¿por qué tiene este código y por qué lo ha modificado por su cuenta? ¿Qué deseas? Para ser compensado por su tiempo no remunerado trabajando en ello? ¿O solo para trabajar menos horas? ¿Su empleador sabe que realizó mejoras en su propio tiempo? Su pregunta no tiene respuesta, ya que está escrita actualmente.
Robert Harvey
3
Bien, ¿cuál es tu pregunta específica? ¿Por qué querría mantenerlo procesal si la arquitectura que desarrolló en su propio tiempo es mejor?
Robert Harvey
8
No hablan tu idioma, por lo que debes aprender el suyo. Así es como es MUCHO. Esta no es razón para huir, porque es así en casi todas partes. Necesita una razón medio verdadera pero plausible para incorporar otro BUEN codificador a bordo, y luego incorporar el tiempo de refactorización. De lo contrario, haga todo lo posible para rellenar sus propias estimaciones y agregar tiempo de refactorización a cualquier proyecto en el que se encuentre. hacer. La gente de negocios generalmente tiene una debilidad en alguna parte. Algunas tareas son más grandes que otras a sus ojos. Rellene los "grandes". Ah, y no se olvide de las pruebas de escritura :) Además, seguir haciendo las horas extraordinarias por ahora - Invstmnt
Trabajo
2
@Robert Harvey, el autor de la pregunta sabe cómo hacer las cosas bien, pero está atrapado en la basura de otra persona y es el único que ve muchos riesgos, es el único que tiene la culpa cuando se rompe la basura. La pequeña empresa está tratando de sobrevivir y sus ventas / ingresos son agresivos, pero la creciente deuda técnica lo está estresando sin que otros lo reconozcan. Necesita una hoja de ruta y consejos sobre cómo salir de este agujero.
Trabajo
1
He cambiado el título de tu pregunta. Esperemos que el nuevo título refleje con mayor precisión su intención. No estoy seguro de que puedas recuperar las horas perdidas; Haría lo que otros sugieren y agregaría algo de relleno a algunas de sus estimaciones para que haya algo de dinero disponible para incorporar sus mejoras.
Robert Harvey

Respuestas:

37

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.

muestreador
fuente
lo que dices son ideas absolutamente geniales. Hace aproximadamente un mes decidí agregar tareas en nuestro rastreador de errores. No me importa que esta tarea no se confirme, cada vez que veo un problema potencial, agrego una tarea y notifico al cliente. La próxima vez que tenga que arreglar algo que esperaba lo antes posible, le recuerdo al cliente la tarea que ya he creado hace unos meses. Espero que ayude.
Andrey Agibalov
17
"Deje de trabajar horas extras no pagadas" debe aplicarse incluso si le encanta el trabajo. No se beneficia de sus horas extra; son. Si desea pasar el tiempo frente a la computadora, hágalo para sus proyectos, en su casa.
Christopher Mahan
1
Después de más de una década en esta industria, todavía nunca he "alcanzado un parche lento". ¿Qué estoy haciendo mal?
sbi
@sbi Creo que podría estar "haciendo las cosas bien" :)
Stephen
13

... 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.

ChrisF
fuente
7

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ó .....

mikera
fuente
Sin embargo, este enfoque hará que sea imposible realizar una refactorización más sustancial.
sbi
1
@sbi: se sorprendería: si tiene buenas pruebas unitarias y un SCM decente para la reversión, puede hacer una gran cantidad de pasos controlados y verificados. Una vez cambié una gran jerarquía de herencia (más de 50 clases) en un modelo basado en prototipos en una serie de refactorizaciones incrementales, ninguna de las cuales necesitó más de un par de horas de trabajo.
mikera
@sbi: Uno nunca debería hacer una refactorización sustancial, solo un cambio / refactorización a la vez. Pequeñas unidades de trabajo, pequeños cambios y, por supuesto, ejecutar todas las pruebas y similares para asegurarse (doblemente) de que no rompió nada.
Cthulhu
@Cthulhu: Si tiene buenas pruebas unitarias, puede derribar y reconstruir casi todo el código que desee, ya que las pruebas detectarán la mayoría de los errores.
sbi
4

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.

Dave Wise
fuente
3

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.
Caleb
fuente
3

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

JohnFx
fuente
2

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.

DKnight
fuente
1
@robertharvey: sí, está limpiando el código en su propio tiempo para que el cliente al que se le facturen las actualizaciones no tenga que pagar más que si el código estuviera bien escrito. Creo que su compañía necesita asumir la mayoría de los costos (si ocurren). Es razonable que el cliente pague parte del tiempo, pero si usted hace una factura excesiva porque el código es una mierda, es una buena manera de perder la buena voluntad y los negocios futuros.
DKnight
2

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.

JeffO
fuente
1

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.

RationalGeek
fuente
1

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

SnoopDougieDoug
fuente