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?
bad-code
porque el código está causando errores y problemas. Lo etiqueté bad-programmer
porque 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.