Culpando a los males de hoy de la deuda técnica de ayer


38

Se ha producido un sorprendente número de problemas de calidad, escalabilidad y carga en una aplicación que actualmente soporto y que originalmente no escribí. Afortunadamente, tengo nuevos proyectos que he estado haciendo desde cero para mantener algo de mi cordura.

El equipo original constaba de 20 desarrolladores (la mayoría de ellos con conjuntos de habilidades obsoletos), sin documentos de requisitos comerciales o probadores de control de calidad, y mal gestionados desde el principio de forma cascada. Los primeros días de producción fueron una pesadilla vergonzosa que implicó parchear código frágil similar a un procedimiento con soluciones aún más frágiles. Más tarde se agregaron características que se agruparon en un modelo de datos que nunca tuvo la intención de admitirlas y no es raro ver el mismo código duplicado 10 veces y ver que los recursos no se cierran de forma segura y las consultas ORM que obtienen decenas de miles de entidades solo tirar todo menos un puñado.

Ahora soy solo yo y cada vez que surge un nuevo problema, reescribo un módulo con mejores estándares y lo hago MUCHO más estable, pero la Administración necesita una explicación adecuada de por qué ocurre todo esto.

Parecen sorprendidos y perplejos ante la idea de que esta aplicación es de baja calidad y se ahoga en deudas técnicas. Afortunadamente, entienden el concepto de deuda técnica y me apoyan en mi búsqueda para erradicarla, y me apoyan y me aprecian mucho, pero siento que sigo culpando al equipo original (que todos dejaron arruinar otro proyecto en un proyecto diferente división).

La conclusión es que no quiero ser "ese tipo" que siempre se queja de los desarrolladores del proyecto antes que él. He visto esta actitud antes de personas en mi carrera que personalmente sentí que eran ignorantes y no consideraban las circunstancias y las influencias de diseño que alentaron a las cosas a ser como eran.

Por lo general, veo esta actitud de culpar al equipo anterior por el diseño y la implementación deficientes de los desarrolladores junior idealistas que no han tenido las experiencias de vida que han tenido y se han beneficiado más miembros senior.

¿Siente que hay una mejor manera, quizás una forma más suave de informar este tipo de problemas a la gerencia sin pisar la reputación de la persona / equipo antes que usted?


17
Es irónico que en una pregunta sobre no jugar el juego de la culpa, pases 3 párrafos completos que comprenden aproximadamente el 50% de tu pregunta despotricando sobre el equipo anterior. Y etiquetó la pregunta [código incorrecto] y [programador incorrecto].
Aaronaught

8
@Aaronaught, está bien, lo morderé, lo etiqueté bad-codeporque el código está causando errores y problemas. Lo etiqueté bad-programmerporque me temo que me estoy convirtiendo en uno culpando al equipo anterior, una excusa cansada y cliché que todos hemos escuchado antes. En lo que respecta a los primeros tres párrafos, tal vez no necesitaba ser tan descriptivo, pero quería pintar una imagen precisa de mi situación inmediata y contar la historia de lo que he reunido hasta ahora.
maple_shaft

2
... Entonces, ¿hay un elemento de despotricar allí? Sí, supongo que sí, pero estoy harto de ser la niñera de una aplicación que funciona como un niño con TDAH con un deseo de muerte.
maple_shaft

2
Simpatizo contigo. Hago. Pero tenemos un sistema de chat si desea despotricar o desahogarse. Las preguntas constructivas deben tener un tono neutral y omitir tales detalles innecesarios.
Aaronaught

La historia de mi vida
Iulian Onofrei

Respuestas:


46

La deuda técnica es como la deuda financiera. Lo llevas (con suerte) estratégicamente en el desarrollo de un programa con la intención de que se pague en el futuro. A veces las personas toman malas decisiones de deuda técnica (como ejecutar una tarjeta de crédito), pero a veces una cierta cantidad de deuda técnica es normal. Decidir no dedicar el tiempo para hacer algo de la manera "correcta" hoy con la suposición de que será necesario cambiarlo en el futuro es completamente normal y debe anticiparse. Por supuesto, hay una línea muy fina, pero pensar que lo hará de la manera correcta la primera vez puede causar su propio conjunto de problemas (parálisis de análisis).

En pocas palabras, cualquier proyecto no trivial que dure más de un par de años necesitará dedicar un nuevo tiempo de desarrollo al pago de la deuda técnica. La cuestión es que esto es cierto incluso si escribe su aplicación de la manera correcta . Si no lo hace, está acumulando deuda sobre deuda, y la gerencia ciertamente puede entender eso si lo presenta de esa manera.

Explique esto a la gerencia y, en lugar de "culpar" al equipo anterior todo el tiempo, puede presentar esto como "lo de siempre".


44
+1 para una muy buena explicación no culpable de cómo un proyecto podría elegir (¡correctamente!) Para endeudarse técnicamente.
Joris Timmermans

1
@Nemi: Una diferencia importante entre la deuda técnica y la deuda financiera es que es mucho más fácil cuantificar la última. Es mucho más fácil saber cuánta deuda financiera le queda para pagar (incluso teniendo en cuenta la acumulación de intereses y las obligaciones financieras recurrentes) que hacerlo con la deuda técnica. Solo señalo esto porque eso es una cosa que exacerba el problema de maple_shaft.
Ben Hocking

2
@Ben: tienes toda la razón. Como con todas las analogías, esta se descompone bajo un microscopio. Sin embargo, la comparación sigue siendo sólida en un alto nivel. Esencialmente prescinde de los detalles y habla con la gerencia a su nivel, como un problema comercial, no un problema técnico. Esencialmente, cualquier proyecto a largo plazo acumula una cierta cantidad de deuda técnica y, como tal, significa que hay un gasto adicional para el desarrollo a medida que pasa el tiempo. Dado que esto está oculto (y ni siquiera se entiende bien), es del mejor interés de todos asegurarse de que se hable de él.
Nemi

2
+1 a "esto es cierto incluso si escribe su aplicación de la manera correcta".
Mauricio Scheffer

1
@radarbob No estoy de acuerdo: al igual que la deuda financiera, no importa si la acumulación se hizo intencionalmente, debido a la mala suerte o la estupidez, alguien tiene que pagarla en el futuro. El término es inherentemente neutral con respecto a la causa.
Hulk

23

En mi opinión, ya estás haciendo esto de la manera correcta: no estás sugiriendo una reescritura desde cero porque "el viejo código apesta", sino arreglando una cosa a la vez.

Para evitar sentir que está culpando al viejo equipo, imagine que probablemente tuvieron que producir este código bajo una gran presión de tiempo. La administración en ese momento probablemente no entendía realmente que el hecho de que el código "más o menos funciona" no significa que cualquier mantenimiento sea posible sin mucho dolor y retrabajo.

Agradezco al antiguo equipo por lograr crear un producto que realmente ofrezca cierto valor comercial; ya no estaría en uso si no lo hiciera. Es posible que se sorprenda de la frecuencia con la que un proyecto no puede ofrecer valor comercial, incluso si está bellamente escrito.


3
+1: culpe a la antigua administración que no pudo entregar un producto de calidad, luego (con suerte) la nueva administración recibirá el mensaje (o se deshará de usted, ambos casos son una victoria en lo que a usted respecta)
gbjbaanb

15
@gbjbaanb - ¡no culpes a nadie! Sal de tu camino para NO culpar a nadie. Simplemente establezca la situación actual y la situación deseada, y haga un argumento lógico de cómo y por qué necesita llegar allí.
Joris Timmermans

Eh, asegúrese de que haya una nueva administración. El mismo jefe aún podría estar allí. E incluso si siguió adelante, está en algún lugar por ahí. Asegúrate de averiguarlo antes de andar tirando personas debajo del autobús.
Philip

Desearía que fuera tan simple como no culpar a nadie. La gerencia insiste en que alguien / algo señale con el dedo. Si no señalo a una persona o grupo de personas, ¿a quién señalo?
maple_shaft

44
@maple_shaft - así que haga el argumento que hice en mi respuesta a la gerencia, y si todavía insisten en "culpar", publique su currículum en tantos sitios como pueda encontrar, porque las cosas le irán muy mal cuando decidir comenzar culpar que a falta de cualquier otra persona a señalar con el dedo.
Joris Timmermans

7

Cuando se me pide que comente sobre el estado actual de un producto problemático, siempre recurro a "es lo que es" y luego empiezo a hablar sobre planes para mejorarlo.

No conoce todos los factores que influyeron en la decisión que creó este problema, tal vez incluso fueron razonables en ese momento. Todo lo que puede hacer es avanzar y mejorar las cosas mañana. Y parece que estás haciendo un buen trabajo: tienes la actitud correcta para esta situación.

Concéntrese en solo informar hechos cuando se le solicite. No tiene que agregar narrativa o comentario; simplemente diga "el sistema falla en el caso X" o "los informes son incorrectos para el caso Y". Luego, agregue rápidamente cómo planea mejorar la situación actual.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.