Culpar a los males de hoy en 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 admito que no escribí originalmente. Afortunadamente, tengo nuevos proyectos que he estado haciendo desde el principio para retener algo de mi cordura.

El equipo original estaba formado por 20 desarrolladores (la mayoría de ellos con conjuntos de habilidades desactualizados), sin documentos de requisitos de negocios o evaluadores de control de calidad, y mal administrados desde el principio en forma de cascada. Los primeros días de la producción fueron una pesadilla vergonzosa que involucró parchar un código similar a un procedimiento frágil con soluciones aún más frágiles. Más tarde, se agregaron características que se integraron en un modelo de datos que nunca tuvo la intención de respaldarlas y no es raro ver el mismo código duplicado 10 veces y ver que los recursos no se cierran de manera segura y las consultas de ORM que alcanzan a decenas de miles de entidades. tirar a todos menos un puñado.

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 deuda técnica. Afortunadamente, entienden el concepto de deuda técnica y me apoyan en mi búsqueda para erradicarlo y me apoyan y aprecian mucho, pero siento que sigo culpando al equipo original (a quien todos dejaron). arruinar otro proyecto en una división diferente).

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

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

¿Siente que hay una forma mejor, tal vez más suave de informar este tipo de problemas a la administración sin pisar la reputación de la persona / equipo ante usted?

    
pregunta maple_shaft 27.07.2011 - 15:40

3 respuestas

46

La deuda técnica es como la deuda financiera. Usted lo toma (con suerte) estratégicamente en el desarrollo de un programa con la intención de que se pague en el futuro. Algunas veces las personas toman decisiones de deuda técnica deficientes (como acumular 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 el supuesto de que será necesario cambiarlo en el futuro es completamente normal y debe anticiparse. Por supuesto, hay una línea fina, pero pensar que la primera vez que lo hagas será la causa correcta, 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 deberá dedicar un nuevo tiempo de desarrollo a pagar la deuda técnica. La cosa es, esto es cierto incluso si escribes tu aplicación de la manera correcta . Si no lo hace, está acumulando deudas y la gerencia ciertamente puede entenderlo si lo presenta de esa manera.

Explique esto a la administración y, en lugar de "culpar" al equipo anterior todo el tiempo, puede presentar esto como "como de costumbre".

    
respondido por el Nemi 27.07.2011 - 16:21
23

En mi opinión, ya lo está haciendo en su mayoría de la manera correcta: no está sugiriendo una reescritura inicial porque "el código antiguo apesta", pero soluciona una cosa a la vez.

Para evitar sentirte como si estuvieras culpando al viejo equipo, imagina que probablemente tuvieron que producir este código bajo una gran presión de tiempo. La administración en ese momento probablemente no entendió realmente que solo porque el código "más o menos funciona" no significa que cualquier mantenimiento sea posible sin mucho dolor y repetición.

Aprecie al antiguo equipo por la gestión para hacer que un producto que realmente ofrezca algún valor para el negocio, ya no estaría en uso si no lo hiciera. Es posible que se sorprenda de la frecuencia con la que un proyecto no ofrece un valor comercial, incluso si está bellamente escrito.

    
respondido por el Joris Timmermans 27.07.2011 - 15:56
7

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

No conoce todos los factores que intervinieron en la decisión que creó este problema, quizás en ese momento eran razonables. Todo lo que puedes 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 tienes que añadir 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.

    
respondido por el Scott C Wilson 27.07.2011 - 17:26

Lea otras preguntas en las etiquetas