¿Cómo puedo convencer a la gerencia para que se ocupe de la deuda técnica?

158

Esta es una pregunta que a menudo me hago cuando trabajo con desarrolladores. Hasta ahora he trabajado en cuatro empresas y me he dado cuenta de la falta de atención para mantener el código limpio y lidiar con la deuda técnica que dificulta el progreso futuro en una aplicación de software. Por ejemplo, la primera compañía para la que trabajé había escrito una base de datos desde cero en lugar de usar algo como MySQL y eso creó un infierno para el equipo al refactorizar o extender la aplicación. Siempre he tratado de ser honesto y claro con mi gerente cuando discute las proyecciones, pero la gerencia no parece interesada en arreglar lo que ya está allí y es horrible ver el impacto que tiene en la moral del equipo.

¿Qué piensa sobre la mejor manera de abordar este problema? Lo que he visto es gente empacando y saliendo. La compañía se convierte en una puerta giratoria con desarrolladores entrando y saliendo y empeorando el código. ¿Cómo se comunica esto a la gerencia para que se interese en resolver la deuda técnica ?

Planeta desolado
fuente
55
"trabajar con desarrolladores" "comunicar esto a la gerencia" ¿Sobre qué preguntas? Desarrolladores o gerentes? ¿Qué comportamiento quieres cambiar?
S.Lott
45
La deuda técnica es como la deuda financiera: a la larga, es mucho más fácil simplemente no acumularla. Pague todas sus facturas técnicas una vez por semana.
Lawrence Dol
77
Mike> Creo que vives en un mundo mucho menos restrictivo ya que los plazos y los presupuestos limitados dominan el mundo en el que vivo. Si el software no se adapta bien a las necesidades futuras y requiere mucho trabajo para solucionarlo, entonces la administración suele estar más preocupada por ignorar y sigue atornillando características. Ahora, muchos compañeros en los que he trabajado colocan hojas de tiempo para que los desarrolladores necesiten registrar su trabajo y si no se invierte tiempo en donde la gerencia ve el negocio potencial, entonces está perdiendo su tiempo.
Desolate Planet
44
Supongo que se podría decir que es un problema con los beneficios a corto plazo frente a los beneficios a largo plazo. Si un equipo de software arregló un sistema de tal manera que las nuevas funciones tardaron menos de una hora en implementarse en lugar de un día, eso es un beneficio inmediato. Si la gerencia lo ve tratando de mejorar el código y va en contra de lo que quiere, está siendo un poco rebelde a sus ojos. Realmente no sé cuál es la mejor solución, pero parece un problema tan común y he visto lo que les hace a los equipos.
Desolate Planet
3
Scott> Para responder a la pregunta, me gustaría cambiar la actitud de la gerencia. Los desarrolladores conocen el código y tienen experiencia de primera mano sobre qué código se debe mejorar para facilitar las cosas. En un trabajo anterior cuando lanzamos una nueva versión de una aplicación, el número de errores seguía aumentando a un ritmo horrible. Me he esforzado por implementar estrategias de prueba, pero a menudo se siente como una causa perdida.
Desolate Planet

Respuestas:

191

Cuando me reuní con mi jefe para discutir esto, dijo que debería incluir la refactorización en todas mis estimaciones. Dijo que no es un problema en el que quiera pensar. En cambio, debería manejarlo.

Este no es un problema en el que la gerencia en general quiera pensar. Ellos no son los ingenieros, tú eres. Simplemente haga de esto una parte tácita de todas sus estimaciones, y verá que la deuda técnica disminuye.

Sin embargo, nunca será perfecto. La deuda técnica, como la deuda de la tarjeta de crédito, es una inversión para hacer que los clientes sean más rápidos y ganar cuota de mercado sobre sus competidores más rápido. Al igual que el crédito, si se gestiona adecuadamente, puede ser bastante exitoso.

jmort253
fuente
30
Mi experiencia es generalmente en la línea de esto. La deuda técnica se limpia a medida que se agregan nuevas características. A veces, las estimaciones para ciertas correcciones / características 'relacionadas' se completan para incluir la limpieza de estas cosas.
Ken Henderson
44
+1 Compartes mis sentimientos exactamente ... excepto que te expresaste mucho más diplomáticamente;)
Michael Brown
77
Buena respuesta. Todavía no he visto una empresa que esté feliz de firmar un proyecto de 'refactorización' que no generaría ningún beneficio para el cliente, solo un código más ordenado. Refactorizar sobre la marcha.
JBRWilkinson
77
"Cuando me reuní con mi jefe para discutir esto, dijo que debería incluir la refactorización en todas mis estimaciones". - Esta es la actitud que adopto y la postura que adoptan muchos desarrolladores en equipos en los que he trabajado. Sin embargo, cuando estos desarrolladores de 9 a 5, como los llamamos, están preocupados por sus revisiones y aumentos salariales, no van a crear más trabajo para ellos mismos. Seguirán lo que la gerencia piense, después de todo, es quien les paga.
Desolate Planet
8
@ jmort253: hay un problema (leve) con esta política de otra manera excelente:> no es posible realizar cambios extensos (es decir, cambiar la base de datos como lo dice el OP). Esos deben ser abordados explícitamente.
Matthieu M.
48

Es como dijo Gandhi cuando se le preguntó si su táctica funcionaría con alguien como Hitler. Él dijo: "Sería difícil". Pero creo que hay un argumento justo de que la respuesta realmente es "No". Lamentablemente, no creo que se pueda hacer lo que intentas hacer. No es que trate de ser pesimista, sino que trato de ser honesto.

El problema para mí no es que los gerentes necesiten convencer. Los mejores ya entienden que la deuda puede ser mortal si no se gestiona. Pero ya sea que lo entiendan o no, ya sean buenos gerentes o malos, todos enfrentan la presión de cumplir, y sus jefes juzgan esa entrega contra una fecha. La calidad solo importa si es extremadamente mala, en cuyo caso es culpa de los desarrolladores, o extremadamente buena, en cuyo caso es la brillantez de la administración lo que lo hizo posible. La calidad solo necesita ser "suficientemente buena".

Creo que me gusta lo que dijo Renesis en su respuesta, porque es uno de los pocos que entiende que la gerencia piensa de manera muy diferente a la ingeniería. Y creo que todos hemos visto la progresión de las empresas para convertirse en fechas y más proyectos gestionados en lugar de centrados en el cliente y la calidad. Con esto, me refiero a compañías típicas, no a las realmente firmes que tienen las agallas para decir "Se hará cuando esté hecho" (como Apple Computer o id Software, y sí, entiendo que a veces las personas no están en libertad para tomar ese enfoque).

Pero aquí está la cosa: las empresas que adoptan el enfoque de calidad primero ... ¿qué notas sobre ellas? Así es, están a cargo de ingenieros, no de vendedores, vendedores, gerentes de proyectos o contadores. Piense en HP, Apple, id, Google, Microsoft e IBM. Todo comenzó y fue exitoso por ingenieros, no por vendedores, aunque los vendedores ciertamente jugaron un papel, y estoy seguro de que muchos debatirían si Microsoft está asociado con la calidad :). Y de esos, los que fueron cuesta abajo se alejaron del liderazgo impulsado por la ingeniería. Sin embargo, hay una gran cantidad de argumentos en esa declaración, ya que hay muchas compañías técnicas que finalmente fracasaron debido a la incapacidad de adaptarse a los tiempos cambiantes y administrar su propio crecimiento. No veo el liderazgo basado en ingeniería como la causa de esos fracasos, para mí eso ' Es un problema de habilidades y perspicacia comercial que son independientes de que alguien sea desarrollador o contador. Sin embargo, en términos generales, creo que hay una dedicación en la ingeniería a los rigores de la responsabilidad y la disciplina que beneficia a las empresas donde la ingeniería es un componente.

En serio, mira a tu alrededor. Falta el liderazgo de TI. El enfoque siempre está en el costo y el tiempo, y rara vez en la calidad, siempre que sea lo suficientemente bueno. Los líderes de TI rara vez se reportan al CEO, ahora siempre es el CFO. TI está atrapado en el soporte de producción y está cada vez más en deuda con los gerentes de proyecto cuyo enfoque está en trozos más pequeños, más digeribles y medibles, no en cambios significativos de valor revolucionario (no es que esto sea necesariamente incorrecto; dividir y conquistar es algo bueno, pero la visión necesita estar allí para el panorama general).

Lamento tomar tanto tiempo en esta publicación, pero al final creo que su pregunta, sobre cómo hacer que la administración se preocupe por la deuda técnica, a menudo se resuelve mejor al encontrar el líder correcto, en lugar de cambiar el existente. Explicar la deuda técnica a los pensadores estándar significa cambiar el enfoque al dinero y al costo, como dijo Renesis, y creo que eso pierde mucho en la traducción; incluso si tuvieras éxito en ello, solo importaría si el líder líder de la compañía lo comprara. Convencer a su gerente intermedio de que haga lo correcto probablemente solo lo despedirá.

Bernard Dy
fuente
43

Lo primero que debe hacer es cambiar la redacción. Llamarlo "deuda técnica" le da a la gerencia la idea de que permitirlo es una inversión de algún tipo, cuando en realidad es más como un virus. (Soy como el Dave Ramsey de la deuda técnica).

Permitir que no se pague tiene un costo enorme que no se puede ver ni cuantificar fácilmente.

Enumere problemas como los siguientes para la administración:

  • Las nuevas estimaciones de características son mucho más altas de lo necesario. O imposible por completo.
  • El código incorrecto genera más código incorrecto
  • La lista de errores crece incluso si los desarrolladores siempre los arreglan
  • Los miembros del equipo se van (esto en sí mismo puede mostrar que hay un problema como se explica en esta excelente respuesta )
Nicole
fuente
77
+1, aunque creo que la última viñeta debería ser "Los buenos / mejores miembros del equipo se van"
Ken Henderson
12
La deuda técnica poco es una inversión a veces. Si está compitiendo con otra compañía y quien lanza primero obtiene el mercado por sí mismos, entonces tiene sentido hacer accesos directos en el código para lanzar más rápido. A nadie le importará que tenga un código perfecto si tiene clientes que no pagan nada.
quant_dev
3
@quant_dev si ve esto como una dicotomía entre "más rápido" y "código perfecto", entonces, por supuesto, pensará de esa manera. No hay ninguna razón por la cual los atajos no puedan ser técnicamente sólidos, en cuyo caso no se consideran deuda técnica.
Nicole
2
@Renesis "No hay ninguna razón por la cual los atajos no puedan ser técnicamente sólidos", eso simplemente no es cierto.
quant_dev
3
Y a veces no es una deuda técnica, es solo un desastre: sites.google.com/site/unclebobconsultingllc/…
TrueWill
30

Mi administración realmente ha comenzado a hacer un esfuerzo serio para abordar la deuda técnica, que es una de las razones por las que me gusta trabajar allí, pero es un esfuerzo a largo plazo y nunca está de más recordarles por qué vale la pena el esfuerzo.

Una de las formas en que mantengo la presión es cuando me solicitan un presupuesto, y podría haberse ahorrado tiempo si no tuviera que lidiar con problemas técnicos específicos de la deuda, lo incluyo en mi presupuesto . Por ejemplo, " este error me llevará 2-3 días para localizarlo, pero si ya hubiéramos abordado estos otros 2 errores de 'baja prioridad' que han estado en la cola para siempre, probablemente tomaría menos de uno " . la respuesta será seguir adelante y arreglar esos otros mientras lo haces.

También estoy de acuerdo con otras respuestas sobre solo considerar las mejoras como parte de su trabajo y hacerlas a medida que avanza si no es demasiado perjudicial. Mi tarea actual consiste en hacer adiciones a un código muy mal diseñado. En lugar de aumentar el desorden escribiendo mi nuevo código para que coincida, paso un poco de tiempo consolidando la funcionalidad común, por lo que enviar un paquete se convierte en una llamada de función de una línea en lugar de repetir constantemente 15 líneas de copiar y modificar ligeramente pegar repetitivo.

Sé que de hecho va a salvar la cordura de algunos mantenedores más adelante. Lo sé porque hoy soy ese mantenedor. Sin embargo, también creo que va a acelerar mi propia tarea actual de obtener y depurar esta característica ahora.

Otra técnica que he usado en el pasado y que debería volver a hacer es mantener una rama DVCS refactorizadora en un árbol de trabajo separado para ese tiempo de inactividad cuando compila, espera una prueba larga o simplemente necesita un cambio de ritmo para un poco cuando estás agotado por un error. Siempre y cuando ocasionalmente se fusione de manera ascendente para no divergir demasiado, puede demorar todo el tiempo que desee en refactorizar los cambios con muy poco esfuerzo marginal. 15 minutos aquí y allá por día realmente pueden sumar con el tiempo.

Karl Bielefeldt
fuente
20

Podrías probar la analogía de la tarjeta de crédito. Pregúnteles "¿se siente cómodo dejando sin pagar los extractos de su tarjeta de crédito durante un período prolongado de tiempo?"

Los gerentes entienden los costos y beneficios, pero (generalmente) no los términos técnicos utilizados por nosotros los desarrolladores. El término "deuda técnica" ya se inventó para ayudar a superar esta barrera de comunicación, pero es posible que deba articularlo más claramente. La mayoría de los gerentes saben muy bien (a menudo por experiencia propia) que los pagos vencidos con tarjeta de crédito crecen con una tasa de interés horrible, por lo que duele dejarlos sin pagar. Esto puede ayudarlos a comprender la gravedad del problema relacionado con la entropía del software.

Pero si esto no los convence, intente reunir evidencia objetiva y hacer algunos cálculos. Por ejemplo, cuánto le cuesta a la empresa, tanto en efectivo como en tiempo perdido, reemplazar a un empleado que se va.

Péter Török
fuente
12

Nadie dará dinero para reemplazar algo que funciona con algo que (con suerte) también funciona.

Lo que puede hacer es proponer reemplazarlo por algo que haga más, es decir, agrupar el servicio de la deuda tecnológica en una actualización que brinde beneficios comerciales instantáneos y tangibles.

Por supuesto, debe ser abierto al respecto, no estamos hablando de "introducirlo" en un nuevo proyecto aquí.

Me parece que el otro lado, el de los desarrolladores, es más difícil de manejar. Básicamente, todo se reduce a esto: para algunos desarrolladores, asegurarse de que su código sea el mejor código posible es un orgullo profesional. Para otros, este es solo otro trabajo y el objetivo es hacerlo rápidamente e irse a casa.

Ninguna cantidad de convincente cambiará esa situación, y si introduce un estándar de calidad de código obligatorio, sus desarrolladores de nueve a cinco encontrarán una manera de trabajar el sistema, mientras que sus desarrolladores dedicados inevitablemente se molestarán por todo el procedimiento (que no es No apuntas a ellos, pero no puedes decir que el desarrollador X debe obedecer las reglas, mientras que Y puede hacer lo que quiera).

Lo que funciona, pero aún puede ser muy frustrante es tener a sus desarrolladores más dedicados y conocedores supervisando la base de código, probablemente una buena compensación entre seguir adelante y ordenar lo que hay allí.

biziclop
fuente
55
+1 Pero esos desarrolladores 9-5, bueno, quieres la puerta giratoria para ellos, idealmente con algún tipo de acelerador.
Orbling
3
@Orbling: +1. Si no les importa lo suficiente, realmente deberían estar trabajando en otro lugar. Es genial tener desarrolladores viniendo a ti con "Acabo de tener esta idea ...".
rapid_now
3
@Orbling En ciertas áreas de desarrollo pueden ser útiles. No soy en absoluto un fanático del "esnobismo de los desarrolladores", pero tienes que encontrar el nicho de todos para que sean útiles. Lo peor que puede hacer es asumir que todos son como usted.
biziclop
Personalmente, creo que la industria está muy sobrecargada de personal. Donde estoy ubicado, la mayoría de los trabajos de software obtienen unos buenos 300 candidatos que solicitan estos días. Con ese nivel de competencia, un empleador puede darse el lujo de contratar empleadores que hagan un esfuerzo adicional y sean mejores que el promedio.
Orbling
"Continúo escuchando a nuestro Arquitecto Jefe" actualizar las actualizaciones a una refactorización para ofrecer beneficios tangibles (puntos de venta) ", así que tendré que secundar esto.
Mario T. Lanza
12

El hecho es que, en muchas empresas, particularmente dada la situación económica actual, cada hora debe facturarse a alguien.

O bajan, rápido .

A menos que los clientes existentes estén dispuestos a pagar por la refactorización, lo cual es muy poco probable a menos que venga con un rendimiento o características significativamente mejorados. Entonces no sucederá en las bases de código más antiguas. Es posible que pueda incluirlo en el presupuesto para proyectos más nuevos, si los clientes tienen mucho dinero, pero a menos que no necesite cambiar las API en la refactorización, no será útil para proyectos más antiguos y bien podría introducir un situación en la que la compañía admite dos bases de código, lo que causa más dolores de cabeza y costos.

Como ingeniero, me encantaría refactorizar el código antiguo, que ya no es realmente adecuado para su propósito, cada vez que algo queda obsoleto o en desuso. Pero como mis doctores en todas las compañías en las que he trabajado me han dicho: "¿Quién pagará?"

Orbling
fuente
12

Siempre trato de limpiar a medida que avanzo. No he terminado hasta que el código esté limpio. El problema con la deuda técnica es que la mayoría de la gente no lo entiende. La mejor manera de abordarlo es no acumular nada. Si sus gerentes confían en sus desarrolladores para decidir cómo resolver un problema, puede hacer que la higiene del código sea parte de cada tarea de programación. Si nunca registra un código incorrecto, no acumula deudas. Si también sigue la Regla de Boy Scout (siempre deje el código más limpio de lo que lo encontró) su deuda existente desaparecerá lentamente.

No veo la refactorización como una tarea separada de la implementación de características. Es una parte integral de esto.

EricSchaefer
fuente
55
No podría estar más de acuerdo: "La deuda técnica es como la deuda financiera; a la larga, es mucho más fácil simplemente no acumularla. Pague todas sus facturas técnicas una vez por semana"
Lawrence Dol
7

Si está tratando con gerentes no técnicos, sería útil si puede convertir su discusión en términos que ellos entiendan. Si puede construir un caso realista para un ROI positivo en el trabajo dedicado a pagar la deuda técnica, podría llegar a algún lado. Ese ejercicio dependerá de sus circunstancias, pero un ejemplo podría ser algo como esto:

Analice la cantidad de tiempo que los desarrolladores se ven obligados a pasar ayudando al Soporte técnico con problemas de producción, luego haga el caso de que arreglar un código antiguo no adecuado A. reduciría la cantidad de problemas de soporte técnico, B. facilitaría que el Soporte resuelva los problemas sin escalar al Desarrollo, y C. reducir el tiempo que el desarrollo gasta en problemas de producción cuando surgen. Póngalo en términos de dólares ahorrados al no tener a los desarrolladores atados haciendo trabajo de soporte. También señale que cada hora que un desarrollador pasa dando soporte es un "doble golpe" porque no solo le está pagando a un desarrollador para que brinde soporte, sino que está quemando el costo de oportunidad de lo que ese desarrollador podría estar haciendo (agregando nuevas características, etc. .)

Sí, algunos de los números serán vudú / humo y espejos ... eso está bien, el secreto sucio de la administración es que saben que la mayoría de los números que arrojan son BS totales siempre y cuando les des algo aparentemente concreto para trabajar, para que puedan tenerlo en la cabeza, tienes una oportunidad de pelear.

crimen mental
fuente
6

Después de esta explicación de la deuda técnica, su gerencia debería estar convencida de pagarla:

Imagina que tienes una cocina muy sucia llena de basura. Antes de preparar una comida, primero debes pasar una hora limpiando. Y es así cada vez que quieres comer. Además, al preparar una comida, debe tener mucho cuidado para asegurarse de que la basura no caiga en su comida.

La cocina es su código, la comida es su producto y comer es vender su producto.

Si pueden darse el lujo de esperar más tiempo para que se implemente un cambio, sin una red segura de pruebas unitarias, entonces hay algo mal en su empresa.

BЈовић
fuente
4

Tiene que ser un argumento muy convincente, en términos del producto original y el caso comercial, que no podría usar ese dinero ahora para hacer algo más importante para mí. Nos guste o no, su gerencia o sus clientes están pagando por esto y usted necesita poder vender para convencerlos.

Reformulemos esto para posicionarse como cliente. Buen viejo juego de roles.

Supongamos que comprara un refrigerador. Y podría comprar una nevera por $ 1000 que funcionó bien de Acme Corp. O una nevera por $ 2000 de Acme Deluxe Fridges que se veía igual en el exterior y tenía las mismas especificaciones técnicas, pero tenía costos de mantenimiento más bajos debido a una arquitectura interna más limpia.

Como cliente, ¿cuál comprarías tú mismo?

¿Y qué creen los ingenieros de Acme Deluxe que es la mejor respuesta?

jasonk
fuente
3
Me está costando mucho determinar tu postura sobre esto. Creo que su respuesta es "depende de lo que quiera el cliente". El problema es que no todos los clientes entienden que el refrigerador de menor costo se derramará, la suciedad desagradable de la sección del congelador, hará ruidos fuertes y, finalmente, dejará de funcionar después de 5 años, mientras que el otro funcionará sin problemas durante 20 años. y no se reemplazará hasta que los propietarios lo consideren pasado de moda y lo revendan a cambio de un nuevo modelo. Aún así, me gusta la pregunta que planteaste. Es sugerente. +1
jmort253
Primera línea: "Tiene que ser un argumento muy convincente [] que no podría usar ese dinero ahora para hacer algo más importante para mí". Utilizo el ejemplo del refrigerador como francamente, no me importa lo que sucede dentro de mi refrigerador. Solo quiero un resultado. (comida fría a un precio razonable). Para ser franco, no me importa si los ingenieros de refrigerador piensan que es un producto mejor internamente. Podría consultarlos, pero realmente no es su decisión.
jasonk
3

La " deuda técnica " puede ser un tema difícil de presentar a la gerencia, ya que es posible que no vean la necesidad. La pregunta podría enmarcarse como si hay un campeón en la compañía que diga: "Mire, estamos tomando X% de tiempo para trabajar en la deuda técnica aquí. Danos 3 meses para mostrarle que esto funciona bien" o algo así. similar. Hay un reclamo hacia la autonomía allí, pero también un marco de tiempo ya que, de lo contrario, la gerencia puede preguntarse cuánto tiempo hasta que vean algunos resultados, que es un territorio bastante peligroso.

Sin embargo, el primer punto es si ven esto o no como un problema. Si la persona con mala visión no sabe nada de anteojos y qué tipo de cambios puede proporcionar, ¿cómo van a entender por qué una prueba ocular podría ser valiosa? La misma idea aquí donde el tema es bastante técnico y desafortunadamente no se cuantifica fácilmente.

JB King
fuente
Estoy totalmente de acuerdo con esto y lo encuentro cada vez más. Recientemente, he estado recopilando una lista de defectos que se han reabierto porque no se implementó una solución adecuada o defectos de naturaleza similar. Esperemos que los desarrolladores dediquen el tiempo dedicado. A veces lo hacen, a veces no, pero este tipo de datos es una base útil para mostrar a la gerencia cómo un producto poco saludable está afectando su negocio.
Desolate Planet el
2
En mi lugar de trabajo actual, las horas extras se asignan por razones equivocadas. Si se invirtiera tiempo en mantener la aplicación saludable en lugar de los problemas de extinción de incendios, se ahorraría dinero en tiempo extra y los desarrolladores estarían más capacitados en lugar de agotados y molestos con la administración.
Desolate Planet el
Pero la gerencia (¡en la mayoría de los casos correctamente!) Lo ve de esta manera. ¡Tengo un magimix de los años 80 que todavía funciona y me estás diciendo que lo reemplace solo porque es viejo y el color no está de moda!
James Anderson
2

Deberías dejar de quejarte al respecto.

Este es el por qué:

  1. Nunca planean usar el software por más de un año
  2. es solo una pérdida de tiempo ajustarlo si su plan es deshacerse de él después
  3. Hay algunos problemas reales que necesitan solución ahora
  4. los programadores solo necesitan aprender a lidiar con el mantenimiento, incluso si no siempre es divertido
  5. quejarse de que sabes mejor lo que hay que hacer es arrogante: alguien más toma la decisión y deberías estar feliz por ello
  6. De todos modos confían en ti para escribir un buen código

Entonces, el mejor camino a seguir es:

  1. Cuando le den una nueva tarea, intente implementarla lo mejor posible en el tiempo dado
  2. Escríbelo perfectamente la primera vez. Si necesita cambiarlo después, cometió un error la primera vez y cualquier cambio siempre va en la dirección equivocada, y es una oportunidad de aprendizaje para los programadores cuando comete errores.
  3. No le pidas tiempo extra, no lo conseguirás, hay plazos que conoces.
tp1
fuente
3
Principalmente estoy de acuerdo, excepto que es bien sabido que incluso el software malo tiene una tendencia a sobrevivir mucho más tiempo de lo que esperan sus creadores. Pero tienes razón, es mejor no quejarse. En cambio, si ve una refactorización a escala limitada que ayudará a la comprensión del código, podría valer la pena seguir adelante y realizar los cambios SIN PERMISO durante su mantenimiento / corrección de errores (y corre el riesgo de hacerlo).
Angelo
@Angelo - ¿No sería mejor expresar tus preocupaciones en lugar de permitir que el equipo sufra en silencio? He visto lo que este problema hace a la moral del equipo y también con la cantidad de tiempo / dinero perdido en horas extras. No lo veo como un "gemido" como tal. Simplemente está señalando los riesgos del proyecto y si sus ideas pueden acelerar los tiempos de entrega y agilizar los procesos, ¿por qué no al menos tratar de expresar sus preocupaciones? Si esto cae de oídos sordos, entonces al menos sabes dónde estás parado.
Desolate Planet el
2
Usted debe quejarse en voz alta , si no es su culpa si de otras personas descifrado del código ( "Usted sabía que esto era un desastre y no le dijo a nadie?"). Ponerse de pie y decir "Hola jefe, esta mierda tarde o temprano golpeará al fanático" es vital para mantener un equipo de desarrollo funcional.
Alex
1

Supongo que nunca ha estado involucrado en un proyecto para reescribir / reemplazar o incluso actualizar el sistema existente.

Estos son algunos de los proyectos más difíciles de completar con éxito. Algunos de los problemas que encontrará son:

  1. Las reglas comerciales se pierden en el tiempo.
  2. La documentación y la implementación están totalmente fuera de sincronización.
  3. Lo que ves como un error los usuarios lo ven como una característica.
  4. Por el contrario, los usuarios verán muchas "características" como defectos.
  5. No conseguirás que los usuarios compren: considerarán tu "hallazgo de hechos" como "nerds que hacen preguntas estúpidas", considerarán el esfuerzo de prueba como una pérdida de tiempo, insistirán en agregar nuevas características, lo que alargará un proyecto. Ya estar retrasado.
  6. Lo más probable es que el código fuente no coincida al 100% con el ejecutable en ejecución.
  7. Mientras su departamento está jugando con la refactorización del desarrollo, el negocio realmente no se está haciendo.
  8. Lo más probable es que su refactorización implique "interfaces mejoradas y más limpias", arrastrando así otros proyectos a su atolladero de entrega tardía y pruebas fallidas.
  9. Después de que el proyecto esté enlatado (más del 50% de estos esfuerzos fracasan por completo), habrá perdido toda credibilidad; deberá mudarse a otra compañía en otra ciudad para encontrar a alguien preparado para escucharlo.
  10. Si el proyecto "tiene éxito", todos recordarán la pesadilla que fue, usted .......

Le insto a evitar cualquier proyecto de reescritura / refactorización como la peste, pueden ser algunas de las experiencias más desalentadoras en la carrera de cualquier profesional.

Hay mucha sabiduría en la frase "Si no está roto, no lo arregles".

James Anderson
fuente
1
"Supongo que nunca has estado involucrado en un proyecto para reescribir / reemplazar o incluso actualizar y el sistema existente" - Incorrecto, 7 años.
Desolate Planet
1
Estoy completamente de acuerdo en que una reescritura completa suele ser un desastre. Pero tengo tres ejemplos en los últimos 8 años de mi carrera. Uno fue un largo trabajo que resultó en que pudiéramos mantener mejor el producto, pero no proporcionó ningún valor comercial; otro fue una breve reescritura que fue un éxito total; el tercero fue una decisión de no reescribir, lo que finalmente mató a la compañía. Elige tu veneno.
Tom Harrison Jr
1

Por mi vida, no puedo entender por qué algunas personas temen ciegamente el cambio: huele a falta de confianza en tus propias habilidades.

Anoche vi un espectáculo en el Parque Nacional de Yosemite y se observó que desde 1940 hasta finales de los 90 no brotó ningún árbol Sequoia nuevo. Se descubrió que la razón era que existía una política estricta contra la quema de incendios forestales y que los conos de pino Sequoia necesitaban el calor del fuego para abrirse y liberar sus semillas.

Usted ve, un incendio cada diez años más o menos era saludable. Eliminó toda la madera muerta y zarzas acumuladas para mantener saludables los árboles (procesos) existentes y dejar espacio para otros nuevos (características).

Estoy en un proyecto en este momento que tiene un caso claro para la reconstrucción: el software heredado fue escrito completamente usando formularios web .NET. Casi toda la lógica de negocios se combina con la lógica de vista de etiquetas HTML / servidor y no puede extenderse a otras aplicaciones ahora que el negocio ha crecido.

La administración está detrás de la tarea porque tienen una cantidad adecuada de confianza en sus desarrolladores, lo cual, me doy cuenta, es un lujo raro.

Sí, pregúntese si una reconstrucción es realmente necesaria. Haz tu mejor esfuerzo para reutilizar el código existente que funciona donde puedas. Integre ese código en la reconstrucción si es necesario. Simplemente no dejes que nadie te convenza de que tener miedo de hacer cambios audaces es la única forma de existir como desarrollador de software.

¡Buena suerte!

Matt Cashatt
fuente
1
¿Cómo responde esto a la pregunta que se hace: "¿Cómo se comunica esto a la gerencia para que se interese en resolver la deuda técnica?"
mosquito
1
@gnat: ¿Cómo responden la mayoría de las "respuestas" a esa pregunta directamente? Ver, por ejemplo, las respuestas de James Anderson, tp1, o cualquier respuesta en la parte superior con más votos. Pero para responder a su pregunta, proporcioné una analogía alternativa que el OP puede usar. Me parece que simplemente no está de acuerdo con mi opinión al respecto. Eso está bien, pero no hay razón para rechazarlo.
Matt Cashatt
1
Según mi lectura, la respuesta principal que usted refiere parece abordar directamente la respuesta solicitada, basada en la experiencia relevante "Cuando me reuní con mi jefe para discutir esto ..." En cuanto a su opinión, prefiero estar de acuerdo con eso, pero voto en la calidad del contenido, no en si apoyo una opinión particular o no estoy de acuerdo. Cambio de pila Q y un modelo de votación es bastante pobre cuando el (mal) utilizados para las encuestas de opinión
mosquito
1
Recomiendo leerlo de nuevo, entonces. Describir una conversación mantenida con el jefe de uno con respecto a un método para cubrir la deuda técnica al completar estimaciones para el trabajo futuro no responde a la pregunta: "¿Cómo se comunica esto a la gerencia para que se interese en resolver la deuda técnica?" ya sea. No obstante, no rechacé la respuesta porque se agregó a la conversación. Entonces, todo lo que ha logrado hacer es silenciar una opinión sobre el asunto con el que está de acuerdo sin una razón sustancial. Los "programadores" deberían ser un lugar donde podamos tener una conversación. No todo es binario.
Matt Cashatt
1

Debe darle a su administración una razón financiera para lidiar con la deuda técnica y un marco para administrar la reducción de esa deuda técnica.

Mantener una hoja de ruta tecnológica es uno de esos marcos. Comenzar con una hoja de ruta lo ayudará a evitar que acumule deudas técnicas y también puede ayudarlo a reducir la deuda existente.

Muchos proyectos exitosos a largo plazo tienen comités directivos y hojas de ruta asociados para guiar el desarrollo. Estos son especialmente útiles cuando hay múltiples equipos de desarrollo e interesados ​​involucrados.

Mi sugerencia es que discuta esta estrategia con sus gerentes (y si es posible con aquellos que toman decisiones sobre dónde se gasta el dinero).

El enfoque general para crear y administrar una hoja de ruta es sencillo, pero requiere el apoyo de su equipo de administración. Primero, define una meta. Defina los elementos de la deuda técnica y desarrolle una arquitectura de sistema objetivo que reduzca los elementos de su deuda técnica. Recuerde, no tiene que ser perfecto, solo viable y mejor de lo que es actualmente. Tenga en cuenta el software, las herramientas de desarrollo, las plataformas de hardware, las principales características nuevas que se pueden agregar al sistema. Haz un análisis de costos. Si tiene la arquitectura deseada, ¿cuáles son los beneficios tangibles de realizar la refactorización? (Los beneficios incluirían un tiempo de prueba reducido, productos de software más confiables, ciclos de desarrollo más predecibles, etc.) Si puede mostrar suficientes beneficios para realizar la refactorización, puede obtener soporte de administración.

Una vez que tenga una hoja de ruta y soporte de administración, desarrolle una serie de pasos (también llamados plan) que debe seguir para llegar a este estado deseado. Puede ser una buena idea reunir un comité directivo que mantenga la hoja de ruta, capacite y eduque a los equipos de desarrollo en la hoja de ruta, y revise periódicamente los cambios para la integridad arquitectónica.

Las hojas de ruta son realmente útiles, y quizás la decimotercera pregunta en la Prueba de Joel debería ser "¿Tiene una hoja de ruta?"

Aquí hay un video de la primera hora de una sesión reciente de hoja de ruta de Red Hat Linux .

Jay Elston
fuente
1

Después de haber estado involucrado en una reescritura importante (no solo de refactorización), puedo estar de acuerdo en que hacer que los financieros estén de acuerdo con el proyecto fue uno de los principales obstáculos. Superar ese obstáculo me obligó a escribir, presentar y defender un informe que señalaba una serie de problemas que significaban que el negocio de las empresas iba a estar muerto en el agua a corto y mediano plazo.

Factores clave para lograr que el acuerdo avance:

  • El código existente estaba en una cadena de herramientas que ya no era compatible (MicroPower Pascal), que solo se ejecutaba en una plataforma de desarrollo casi incompatible (PDP11-23).
  • Encontrar desarrolladores que pudieran trabajar en herramientas y objetivos se estaba volviendo casi imposible.
  • El hardware objetivo ya no estaba disponible si se necesitaban repuestos y el fabricante se estaba volviendo cada vez más reacio a proporcionar un servicio de reparación.
  • Los problemas en el código resultaron en una insatisfacción del cliente fácilmente identificable y costos directos de servicio.
  • Agregar nuevas funciones o incluso corregir errores fue casi imposible debido a las limitaciones del hardware de destino, lo que resultó en la necesidad de refactorizar otras áreas para proporcionar espacio al abordar problemas.
  • Con un tiempo de construcción de 8 horas, desarrollar y probar cualquier cambio fue costoso.

El informe detalla los problemas, con estimaciones de los costos en curso, y ofrece 3 opciones:

  1. Congelar donde estábamos con posiblemente ni siquiera la corrección de errores en un futuro próximo.
  2. Optimice el código solo para el espacio, sin tener en cuenta la capacidad de mantenimiento, señalando que cualquiera que intente mantener el código optimizado debería ser más inteligente que quien hizo la optimización.
  3. Vuelva a implementar, con capacidad de prueba y facilidad de mantenimiento como factores importantes, en un lenguaje estándar (ANSI C) estándar de la industria, en hardware COTS nuevo y de bajo costo (PC-104), con múltiples proveedores disponibles con un proveedor interno. tarjeta de interfaz diseñada para permitirle trabajar con el hardware existente restante. Al agregar un conjunto limitado de nuevas características como parte del desarrollo, como el almacenamiento no volátil, un temporizador de vigilancia para proporcionar un reinicio automático en una condición de falla, algunas unidades se bloquearon varias veces al día y requirieron una llamada de servicio de £ 40 para restablecer , mejores diagnósticos en el proceso.

Después de obtener la tercera opción, mi contrato de 3 meses se convirtió en 3 años de trabajo muy duro, tanto en el desarrollo del nuevo software como en el hardware, pero con un muy buen resultado.

Para los casos con una deuda técnica menos extrema, tiendo a adoptar lo que llamo refactorización de guerrilla:

Cuando hay un problema con un módulo específico:

  1. Escriba un conjunto de pruebas que demuestren el problema que también pueden fallar sin refactorizar
  2. Refactorizar como parte del desarrollo señalando que las pruebas siguen fallando.
Steve Barnes
fuente