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?
fuente
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.Respuestas:
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".
fuente
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.
fuente
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.
fuente