La situación normal aquí sería que trabaje con colegas y la gerencia para discutir los beneficios de reescribirlo, conseguir que sus compañeros de trabajo participen, proporcionar documentación, proporcionar estimaciones de tiempo, dividir el trabajo y abordarlo. De esa manera, primero obtiene la aprobación de los gerentes , discute varios problemas como equipo y forma un plan para superarlos. Entonces, será mucho más probable que los compañeros de trabajo participen en el proyecto en su conjunto, ya que tuvieron voz y voto para impulsarlo. Si algún compañero de trabajo realmente no quiere hacerlo en ese momento, entonces hay poco debate, ya que a) tuvieron una amplia oportunidad de opinar sobre el proceso yb) la gerencia lo aprobó como un proyecto acordado, por lo que su posición es clara.

Sin embargo, en este caso, parece que siguió adelante y lo hizo solo (o al menos hizo la mayor parte), lo que podría alejar a otro desarrollador que entiende perfectamente el sistema antiguo, pero que no necesariamente está familiarizado con las nuevas bibliotecas. , herramientas, tecnologías, paradigmas de código y prácticas de desarrollo que está utilizando. Sí, hay un buen argumento para decir que debería haberse perfeccionado y mantenerse al día, pero en la práctica eso a menudo no sucederá.

Entonces dices:

Cualquier ingeniero de software competente vería el código e inmediatamente se pondría de mi lado.

...y perdóname por decirlo, pero eso parece bastante... audaz. Estas cosas rara vez son así de blanco y negro.

Esta parte en particular me pone nerviosa:

Al portar parte del código, encontré muchos errores que solucioné en el camino que deberían haberse evitado pero no pudieron, ya que no hay forma de escribir pruebas para el código anterior, ni hay un manejo/registro de errores adecuado. . Todas las señales apuntan a que la mudanza es una buena idea.

Si no hay un manejo de errores adecuado, no hay pruebas unitarias, etc. en el código anterior, ¿cómo puede verificar que se comporta de la misma manera? ¿Cómo puede verificar que los "errores" que ha corregido no eran en realidad casos de esquina y que nadie confiaba en ese comportamiento? ¿Cómo puede garantizar absolutamente que no introducirá ningún cambio crítico y de última hora con el nuevo código? A la gerencia y a los clientes realmente no les importa cuán bueno es el código, les importa que funcione. Si significa que la implementación lleva más tiempo pero los clientes están contentos y no se van, entonces es una compensación que vale la pena en lo que a ellos respecta.

Para responder a la pregunta directamente aquí: logra que la gerencia se involucre demostrando el ahorro de tiempo y produciendo la documentación y los recursos necesarios para mejorar las habilidades del otro desarrollador y lograr que se incorpore. Sin embargo, eso no es rápido, es largo y difícil. En realidad, en mi humilde opinión de todos modos, deberías haber abordado la situación de manera muy diferente para empezar.

Tienes un par de problemas aquí relacionados con tu falta de habilidades de comunicación. No sé qué tan bueno es tu código o qué tan malo es el código anterior, pero veamos lo que has escrito aquí.

1. No menosprecies a los demás ni vengas de un lugar de arrogancia

Lo que debo hacer es explicar que tengo mucha más experiencia y he hecho este tipo de trabajo en el pasado con resultados estelares.

Deja de mirar cosas como esta. Apelaciones a la autoridad como esta no ganarán a nadie. No habla del valor de su código, no destaca ningún beneficio, literalmente solo dice "Creo que soy el mejor en esto, así que lo estamos haciendo a mi manera". Todo esto hará que tus compañeros de equipo se enojen. No es lo que quieres cuando no tienes su aceptación.

2. Tranquilízate con la jerga técnica

También me estoy atascando al tener que escribir mucha 'documentación' explicando por qué esta nueva arquitectura es mejor, pero es completamente técnica (hablando de SOLID, pruebas unitarias, inyección de dependencia, etc.) no entenderlo

Parece que tu otro compañero de equipo tampoco lo entiende, así que cambia un poco el idioma. Necesita este documento no solo para obtener la aceptación de la gerencia, sino también la aceptación de sus compañeros de equipo. Habla mucho sobre cosas como SOLID, pero el no programador promedio (o incluso los programadores mayores) no sabrán qué es, así que use el término, explique qué es y explique los beneficios del marco. Luego úsalo con moderación. Haga esto con toda la terminología técnica. Necesita esta documentación para la compra de su gerente

3. Añada algún punto de vista de gestión

Soy un arquitecto de software consumado y fue muy fácil. El nuevo código es totalmente comprobable por unidad con inyección de dependencia y registro completo, por lo que cualquier error y problema es muy fácil de rastrear.

Cosas como esta son buenas. Desde un punto de vista técnico. Lo que debe hacer ahora es traducir esto en términos de gestión, que es simplemente seguir las cosas hasta su conclusión lógica relacionada con los costos y el rendimiento . Estos costos pueden reducirse a dinero o al tiempo de los empleados (ya que le pagan por su tiempo). Por ejemplo:

"Soy un arquitecto de software consumado y fue muy fácil. El nuevo código es totalmente comprobable por unidad con inyección de dependencia y registro completo, por lo que cualquier error y problema es muy fácil de rastrear, lo que reduce drásticamente la cantidad de horas-hombre requeridas para el trabajo de mantenimiento y reparación de errores y, por lo tanto, la reducción de los costos involucrados en estos trabajos, tanto al hacer que sea mucho más fácil para los desarrolladores encontrar el código problemático como al detectar problemas con el código nuevo en versiones más nuevas antes de que lleguen a la siguiente etapa en el ciclo de vida del desarrollo. "

Varias otras respuestas aquí también brindan excelentes gemas para ejemplos de esto. Trabaje estos en donde pueda y no tenga miedo de pensar en más.

4. Aborda las preocupaciones de tu compañero de equipo

Ahora, abordemos el argumento de su compañero de equipo para mantener el código original: 'Funciona'. De acuerdo, tal vez no siempre funcione, pero se ha confiado en él durante algunos años. Puede proponer a la gerencia que ejecute un sistema de prueba con su implementación al mismo tiempo que otro sistema que ejecuta el código original. Tal vez incluso inicie algunos casos de prueba, incluidos algunos que espera romper el código original. De esta forma, tu compañero de equipo ya no tiene ese argumento porque les has demostrado a todos que tu código también funciona, e incluso funciona mejor .

5. Abordar factores no mencionados (pero aún importantes)

Agreguemos otro argumento que el compañero de equipo podría usar: 'Todos conocemos el código original'. Esto es un poco más difícil de derribar porque es inequívocamente cierto, genera un impacto en los costos que la administración comprende y nada de lo que pueda hacer en su código puede aliviarlo por completo. Su mejor mitigación está en su documentación , las mismas cosas por las que dice que está atascado.

Por lo tanto, su documentación debe lograr dos objetivos:

1) Persuadir a la gerencia de los beneficios de su idea (hablé de esto antes)

2) haga que sus compañeros de equipo estén al día (o al menos tanto como sea posible sin prueba de fuego) en su código.

Solo cuando haya abordado estos 5 puntos podrá solucionar el siguiente problema:

El tema es que la dirección nos mira a los dos y no sabe a quién creer.

A los clientes y la gerencia no les importa si algo está bien codificado. Se preocupan por si funciona en un grado aceptable, se preocupan por su costo y se preocupan por si lo reciben a tiempo.

La mejor manera de justificar sus decisiones es explicarlas en términos de horas de trabajo y costos.

Las medidas de ahorro de tiempo deberían hablar por sí mismas. Si sus cambios ahorran, por ejemplo, 2 horas de trabajo por día, eso significa 10 horas de trabajo por semana o 500 por año. Suponiendo una cifra completamente arbitraria de 25 € por hora-hombre en costes laborales, se ahorran 12.500 € al año que pueden destinarse a tareas más productivas.

Si sus cambios significan una reducción en la cantidad de tiempo dedicado a corregir defectos, es más tiempo que dedica a crear valor para la empresa en términos de nuevas características que los clientes pueden pagar. Los clientes no pagan por las correcciones de errores, pagan por las características. Cuanto menos tiempo dedique su equipo a corregir errores, menos dinero desperdiciará la empresa, más dinero ganará el equipo para la empresa.

He estado en una situación similar a la tuya más de una vez. Lo que parece que te estás perdiendo está en un código tan viejo y desordenado que es realmente difícil saber qué es un error y de qué funcionalidad depende la gente. También es muy difícil ver casos de esquina importantes que se han solucionado. Su "alborotador" es el que posee la mayor parte de ese conocimiento.

Ahora es un poco tarde, pero lo mejor hubiera sido involucrarlo en casos de prueba desde el principio y preguntarle sobre cada pequeña cosa que le parezca un error y sobre cada condición límite. Si hubieras hecho esto, estaría mucho más seguro de que realmente entiendes estas cosas. El conocimiento de las "últimas técnicas" no es más importante que el conocimiento del dominio. Necesitas ambos para escribir un software robusto.

Tampoco tiene forma de verificar que el sistema se comporte como el anterior. Escribir pruebas que se ejecutan en el sistema anterior es más lento, pero le permite ser más intencional sobre qué comportamiento elige conservar y qué compatibilidad con versiones anteriores elige romper.

Así que involúcrelo en esas cosas ahora, en la medida de lo posible. Cuanta más información pueda obtener de él, mejor será el resultado y mejor aliado tendrá.

Mostrar, no decir

Esto es axiomático para la escritura, pero con toda honestidad también es axiomático para el lugar de trabajo. No hables [teorías] sobre las mejoras que estás haciendo, muestra cómoson mejoras [implementadas]. La jerga es una excelente manera de abreviar una descripción prolija de lo que es una estructura en particular cuando se habla con otro experto en el dominio, dada la presunción de que otros expertos en el dominio entienden a qué se traduce, pero la jerga también es algo que las personas que ellos mismos no entienden. realmente entiendo de lo que están hablando escondidos detrás. También es un peligro cuando se habla con alguien que no "habla" esa misma jerga, ya que puede parecer pretencioso o intencionalmente ofuscador, o incluso como una falta de comprensión de las necesidades del proyecto en su conjunto (particularmente en relación con objetivos empresariales más amplios) frente a la visión desde la perspectiva de un solo miembro de lo que en realidad es solo un conjunto de posibles herramientas para trabajar en ese proyecto.

Si ha realizado mejoras reales y deterministas, entonces también son medibles .

Esto va más allá del mero desarrollo de software, y es algo en lo que siempre debe centrarse al realizar cualquier proyecto en el lugar de trabajo.

Al presentar un proyecto, está bien discutir cosas que son conceptuales o proyecciones basadas en esos conceptos (pero idealmente debería tener datos de punto de partida para mostrar por qué el statu quo podría ser un problema que necesita solución, en lugar de solo presentar soluciones a algo eso no es claramente un problema).

Al defender un proyecto, desea poder demostrar que hay mejoras reales que se están logrando o se han logrado. Este es el lenguaje en el nivel meta del proyecto/negocio en sí mismo, en lugar de hablar simplemente de una herramienta técnica específica que no logra transmitir ampliamente la importancia de las prácticas empleadas y las elecciones realizadas.

Idealmente, tiene datos, y los datos más fuertes son longitudinales con similares en comparación con similares (lo mejor que se puede hacer)

La forma en que desea abordar esto si tenía datos anteriores a sus cambios depende de usted. Idealmente, compararía algo que mantenga las cosas en gran medida equitativas y que no se deba a los caprichos de la aleatoriedad.

Al mismo tiempo, cuando hablamos de fallas, las fallas generalmente no se detectan de manera confiable y repetible, ni todas las fallas son iguales, por lo que esto siempre será un problema al hacer comparaciones entre el antes y el después.

Para algo como esto, aquí hay algunas cosas que se pueden usar, pero deben prestar atención al hecho de que sin un período de tiempo lo suficientemente largo para la significación estadística (y una forma de determinar qué constituye eso en este caso) usted está gradualmente solo jugando con números:

• Tiempo desde el informe inicial del problema hasta encontrar dónde está el problema dentro del código fuente
• Tiempo desde encontrar el lugar del problema hasta lograr una solución
• Tiempo promedio para resolver el error informado
• Número promedio de errores registrados por ventana de tiempo razonablemente enmarcada [semana/mes/trimestre]
• Horas promedio de desarrollador dedicadas por ventana de tiempo razonablemente enmarcada trabajando en errores

Es posible que no tenga acceso a todos estos, pero su gerente o el gerente de proyecto para esto sí.

Debido a que esto no es algo en lo que los datos van a ser consistentes, otro enfoque que puede tomar es encontrar incidentes individuales comparables tanto antes como después de las mejoras (modalidades de falla muy similares, etc.) y crear comparaciones de estudios de casos. Recorra el proceso de reparación en cada caso, el tiempo que lleva cada paso, etc.

También se pueden hacer cosas similares para los cambios relacionados con las mejoras de características, si su re-arquitectura fue exitosa. Tenga en cuenta que querrá mostrar aspectos que reducen las fallas por adelantado y, por lo tanto, ahorran tiempo a largo plazo. Si es posible, muestre la cantidad de fallas incurridas en una adición de función anterior o un cambio similar, los costos de tiempo promedio relacionados y luego muestre cómo los costos iniciales quizás más altos de la metodología más nueva se amortizan con el tiempo. No se limite a hablar de las teorías relacionadas. Muéstrelos tal como se aplican en contexto.

Levanta, no empujes hacia abajo

No voy a hacer suposiciones sobre cómo te has estado comunicando con los demás sobre esto, pero está bastante claro que has logrado pisar al menos un par de dedos de los pies. No se trata de culpar , sino de encontrar formas positivas de avanzar o al menos mitigar la situación.

Este es quizás el verdadero problema subyacente al que se enfrentará ahora.

Es fácil encontrar situaciones como esta extremadamente irritantes y estresantes. Si bien no es necesariamente justo, la mejor manera de salir adelante suele ser mantener la calma y hablar solo de aspectos positivos que miran hacia el futuro en lugar de hablar mal, especialmente en términos de trabajos anteriores. No denigre el trabajo anterior, no lo llame por estar desactualizado, solo hable sobre los efectos demostrables de sus mejoras.

A veces te harás enemigos por hacer un buen trabajo, y no puedes controlar esto. Lo que puede hacer es tratar de parecer que lo ha manejado con calma y madurez y que ha sido el que se acercó y trató de levantarse en lugar de que el que está parado allí sea un imbécil al respecto.

El mejor enfoque, siempre que sea posible, es reclutar personas que puedan crear problemas a su lado antes de tiempo. Una vez que las cosas empiezan a ir cuesta abajo, esto se vuelve complicado o imposible: el momento ideal es antes. Muéstreles , individualmente y desde su perspectiva, cómo esto les hará la vida más fácil, no la hará más difícil (nuevamente, tenga cuidado con la jerga, incluso si habla con alguien más en su profesión cuando se trata de esto) y, con suerte , involucren algunas cosas que incluso podrían encontrar emocionantes. Esto requiere realmente entenderlos hasta cierto punto. Averigüe cuáles son sus preocupaciones en realidad (fuera de un entorno de grupo) y alívielas y muestre cómo esto será una mejora para ellos., no solo para el negocio/proyecto.

Idealmente, esto no se trata solo de usted, es el tipo de cosa en la que, éticamente, a todos nos gustaría que todos los que nos rodean tengan una buena experiencia laboral y sean felices.

Tenga en cuenta que esto no siempre es posible. Pero al menos en entornos grupales, cómo te comportas es algo sobre lo que tienes un mínimo de control, por lo que ese es el momento de no hablar mal de alguien, no denigrar el trabajo de nadie más (o preocupaciones, perspectivas o quejas reales), y solo concéntrate en tus aspectos positivos.

Si alguien está planteando inquietudes, utilícelas como un eje de cómo fue "un gran punto para mencionar" porque le gustaría abordar cómo esto será una mejora en el contexto de esas inquietudes. no descarteslas preocupaciones. No invalides el acto de tener preocupación. Encuentre un ángulo positivo que mire hacia adelante. No se atasque en los detalles si las cosas se están desviando demasiado, está bien decir que estaría feliz de entrar en más detalles por separado con respecto a una inquietud determinada, pero por ahora quiere volver a asegurar que en términos de los aspectos más amplios de esa preocupación, las cosas están bien abordadas. Programe una reunión relacionada, en el lugar si es necesario. Aplaza cualquier descarrilamiento relacionado a esa reunión. Probablemente deba asegurarse de que la persona que los supervise a usted y a esta otra persona esté de acuerdo con esto de antemano (y definitivamente no querrá hacer nada como esto sin que estén presentes).

Este es un enfoque que puede adoptar para verse como alguien que hace las cosas y también maneja los desacuerdos en el lugar de trabajo de manera productiva en lugar de crear dolores de cabeza para todos los que están por encima de usted. Idealmente, no es solo cómo apareces, sino que termina siendo así.

Una consideración final es que cuando esté haciendo cosas que se puedan interpretar para hacer que otra persona o su trabajo se vean mal, tómese el tiempo para resaltar todo lo bueno que han hecho, cómo impacta positivamente o facilita su trabajo, y cómo usted simplemente están parados sobre sus hombros para dar un paso adelante. Lo ideal es involucrarlos en esto: pedirles que comenten algún aspecto relacionado, o mejor aún, que expliquen algún detalle. Déles espacio para que sigan luciendo bien en relación con lo que está haciendo, incluso si gran parte de eso podría verse como la eliminación de su código . Busque formas de cambiar la perspectiva de esto para que no se trate de deshacerse de su trabajo .

Reflexión de imagen más amplia

Una cosa que debe dar un paso atrás y considerar es que si tiene un colega que no se mantiene al día con las prácticas más modernas pero que se ha dedicado esencialmente al proyecto, es posible que no esté alcanzando los objetivos comerciales que cree que tiene.

Claro, desde tu perspectiva, esto es una pérdida de dinero. Puede ser. Puede que no lo sea. Sus preocupaciones sobre cuánto funcionan o no desde su perspectiva son notables, pero dependiendo de su posición, es posible que no tenga una visión más amplia en relación con esto. Nadie es individualmente indisponible, pero a veces hay equilibrios involucrados en reemplazar a alguien donde no vale la pena hacerlo, pero reducir la carga de trabajo en ese individuo no lo libera para nada más significativo, momento en el que es mejor gastar los recursos relacionados en otra parte. en lugar de mejorar lo que se les ha asignado o en lo que se han centrado.

No es algo con lo que personalmente esté de acuerdo, pero vale la pena ser consciente de que a veces hay realidades políticas más amplias en juego, y trastornar los mundos bastante estables de ciertas personas puede ahorrar algo de dinero, pero puede que no valga la pena hacerlo desde otros puntos de vista. Cada vez que haga esto, debe estar preparado para mostrar ahorros significativos . E idealmente, debe poder hacerlo sin hacer que otra persona se vea mal o sin convertirla en su enemigo en el proceso.

El software no se produce sin las personas. El software no es útil excepto en la forma en que sirve como herramienta para las personas. Lo mismo ocurre con el trabajo de desarrollo. Sí, implica decirle a la computadora qué hacer. Pero también se trata de trabajo en equipo y comunicación. Diría que lo más importante es el trabajo en equipo y la comunicación .

La mayoría de los principios de desarrollo de software que menciona son, en esencia, realmentesobre la creación de marcos coherentes al servicio del trabajo en equipo, la comunicación (incluso cuando se trabaja individualmente, esto es cierto, ya que se trata de comunicarse con su yo futuro) y las realidades básicas de la falibilidad humana. Ha tenido un lapso en la comunicación con los miembros de su equipo y esta fricción ha sido el resultado. Es fácil despreciar la "política del lugar de trabajo" como algo con lo que la gente "no debería tener que lidiar para hacer las cosas", pero en realidad, lo que eso realmente significa es que necesitamos comunicarnos entre nosotros para avanzar como equipo. Idealmente, este es el rol de alguien que está administrando el equipo. Pero la realidad es que si quiere ser alguien que hace las cosas y realiza cambios positivos significativos, también necesita manejar las expectativas y la comunicación con sus compañeros de trabajo.

Es fácil pretender que principios como SOLID, TDD, etc. son algo que un individuo puede implementar e implementar a través de cambios radicales en un proyecto mal codificado, pero en realidad hacerlo puede ser contraproducente en términos de los objetivos subyacentes. de SOLID y principios y teorías similares de arquitectura de software. Al igual que el mejor algoritmo implementado por software se vuelve inútil si ninguna persona que lo necesita puede usar el software relacionado, el software mejor diseñado es inútil en términos de esos aspectos arquitectónicos si el equipo que trabaja en él ya no puede hacerlo de manera efectiva ( esto ciertamente corta algunos otros ángulos relacionados para el propósito de esta discusión).

A veces, esto apunta a la necesidad de un cambio en el personal, pero a menos que esté en posición de tomar decisiones relacionadas, es importante recordar que esa no es realmente su elección o su posición. Seguir adelante por su cuenta, particularmente si se ha desarrollado y acordado una línea de tiempo diferente, podría ser incluso el peor movimiento posible, y podría estar creando un lío peor para usted que el que está justo en su cara, porque otras personas podría haber tenido planes sobre cómo manejar la situación y ahora, en cambio, simplemente explotó. El objetivo de la mayoría de los principios modernos de la ingeniería de software es dejar de fingir que el código está escrito en un vacío perfecto, así que recuerda, en realidad se trata de ser realista acerca de las personas involucradas.. Esto incluye al resto del equipo.

Dudo que vaya a obtener algún beneficio en esto, es muy difícil justificar volver a escribir cualquier cosa para la administración sin ofrecer una nueva funcionalidad, son cosas nuevas y brillantes para jugar con lo que la administración se preocupa, cuanto más nueva interfaz de usuario involucrada, mejor. Acabo de convertir un dinosaurio pesado de un solo hilo en una obra maestra de varios hilos y a nadie le importó una mierda porque no había nada nuevo en lo que pudieran hacer clic en la pantalla.

Entrenador El Veterano

Otras respuestas han dado buenos consejos sobre cómo lidiar con el código y la administración heredados. Quiero centrarme en lo que creo que es su problema principal: tratar con el desarrollador original. Así que no estás de acuerdo en muchas cosas. Si quieres que deje de socavarte, debes incluirlo en tu equipo. Lo que significa que lo necesitas para ver el mundo como tú lo ves. Y la forma de hacerlo es comenzar por entender cómo es su mundo, con detalles significativos.

Lea el código heredado e intente destilar los patrones y las reglas implícitas con las que no está de acuerdo. Tome nota de estos, porque aquí es donde desea estar en la misma página. Luego, piensa por qué no estás de acuerdo con ellos. No se concentre en por qué el patrón heredado es malo . Concéntrese en por qué su patrón de reemplazo es mejor , pero también reconozca el Teorema fundamental de la ingeniería: todo es una compensación . Incluso su patrón "mejor" tiene una debilidad bajo algunas condiciones. Debe poder identificar y comprender estos modos de falla para argumentar con éxito que son menos relevantes para los escenarios en cuestión. Una vez que haya hecho este trabajo de preparación, estará listo para el siguiente paso.

Programación en pareja

Dile a tu amigo que comenzaste con el pie izquierdo, que lamentas ser un imbécil arrogante y condescendiente, y que solo quieres descubrir cómo estar en la misma página. Elija un código que personifique los antipatrones que identificó anteriormente y observe la versión anterior frente a la versión "mejorada" una al lado de la otra. Pídele al desarrollador que critique a los dos y dale mucho tiempo y espacio para hacerlo. Busque oportunidades para estar de acuerdo con él, en lugar de estar en desacuerdo. Estás tratando de construir puentes en este punto. El desacuerdo ya está implícito. Después de que haga sus observaciones, haga preguntas capciosas para ilustrar por qué cree que su versión es mejor. En particular, presente escenarios de ejecución de código donde su código es obviamente superior. En el mejor de los casos, tenga a mano casos de prueba (unidad o aceptación) queilustre la superioridad de su versión, y solo pídale que las revise.

Tu objetivo no es atrapar al tipo en una trampa, sino ayudarlo a ver el mundo desde tu perspectiva. Y eso solo funcionará si primero validas su perspectiva en algún nivel. En particular, debe ser exquisitamente sensible a la historia . Muchas cosas que hoy consideramos "malas" eran comunes, o aceptadas, o incluso buenas hace décadas, porque la tecnología era diferente, el conocimiento era diferente, el hardware era diferente. Intente decirle a Grace Hopper que "GOTO se considera dañino". Ella respondía: "Joven, me gustaría verte escribir un programa ensamblador sin instrucciones JMP. Vuelve cuando hayas terminado".

Eso significa que puede y debe comprender la arquitectura del sistema en el contexto de cuando se construyó por primera vez . Incluso si no era tecnología de punta en ese momento, es posible que se haya construido sobre patrones relativamente maduros que luego fueron reemplazados. Recorrerá un largo camino demostrando cierta conciencia y respeto por esta historia de desarrollo. Todo esto es para decir lo más importante que debe aprender: "El código no es bueno o malo . Es bueno o malo en relación con algún contexto ". Es muy posible que si estuvieras presente cuandoel código se escribió originalmente, es posible que lo haya escrito de manera similar. Hace apenas una década, estaba discutiendo con todo mi equipo en una importante empresa de tecnología Fortune 100 sobre la virtud de las pruebas unitarias. No hay forma de que tenga esa conversación hoy. Muchas cosas cambian con el tiempo.

Pedir ayuda

Si su amigo es especialmente intransigente, simplemente elija un error para corregirlo en una parte del código que no haya refactorizado. Pídale que mire con usted en él. Diga: "No tengo el contexto para depurar este código de manera eficiente. ¿Puede mostrarme su enfoque para esto?" Deja que te guíe usando su proceso. Cuando haga algo que invoque el conocimiento tribal, haz que se detenga y diga: "Oh, ¿alguien más sabe eso?" "Por supuesto que no." "Ok, porque no lo hubiera adivinado con solo mirar el código. ¿Podemos tomarnos un momento para documentarlo?" Después de un tiempo, el hecho de que lo tomen de la mano le pondrá los nervios de punta y se dará cuenta de que solo porque es fácil para él navegar por el código, puede ser complicado y frustrante para cualquier otra persona hacerlo. Si realmente quiere llevar el punto a casa, haz que mire con el desarrollador junior mientras miras por encima del hombro de todos. Entrene al desarrollador junior para que use el mismo enfoque de cuestionamiento en lugar de desafío que usted.

Si tienes suerte, se frustrará y dirá algo como: "Ok, si eres tan inteligente, ¿cómo lo harías?". Luego diga: "Bueno, tenemos un informe de error que muestra que hay un error en alguna parte del código que he refactorizado. Echémosle un vistazo". Luego, déjelo navegar por su nuevo código y que lo cuestione o desafíe. Utilice las pruebas unitarias que ha escrito para ayudar a aislar el error y deje que el desarrollador junior conduzca durante parte del tiempo para ilustrar que no se trata solo de él o de usted, sino de todo el equipo.

Idealmente, si se ha centrado en la empatía y la calidad, en lugar del juicio y la grosería, entonces lo ayudará a ver que realmente ha realizado mejoras valiosas, en lugar de simplemente jugar con el sistema que construyó durante una década. En lugar de insistir en que usted es el arquitecto omnisciente que traerá bondad y luz a todo el código, comience de nuevo con una buena dosis de humildad y deje que su código hable por sí mismo. Si es un codificador razonable, eventualmente tendrá que reconocer que mejor código es mejor código con el que incluso él preferiría trabajar. Y si no puedes llevarlo hasta ese punto, es posible que tenga más que ver con tu actitud que con la de él. Tenlo en cuenta, y buena suerte.

TL; DR: si no estaba exagerando, es posible que no haya nada que pueda hacer por ese proyecto. Pero podría intentar llamarlo un nuevo proyecto y ejecutarlo por separado.

He estado casi exactamente en tu situación más de una vez. No puedo decir que tengas razón, obviamente, ya que no sé todo acerca de tu proyecto en particular, pero a veces realmente es blanco o negro como lo dices, a pesar de lo que otros digan.

Para mi primer empleador en mi trayectoria profesional, tuve la suerte de tener tiempo de inactividad también. Seguía viendo tantos errores horribles por parte de un par de desarrolladores que decidí ayudar. Se negaron, pero yo personalmente fui una de las personas que tuvo que lidiar con las consecuencias de su basura cuando la gente se quejó, así que les pisé los dedos de todos modos.

Hice una versión mejor. Estaba en contacto más directo con los usuarios finales que con el tipo al que estaba pisando los dedos de los pies, así que incluso les pedí que lo probaran. Les encantó y algunos cambiaron a él.

Nuestro propio gerente de servicio al cliente (un tipo de computadoras que entendía las ramificaciones técnicas) dijo que quería que la versión oficial fuera reemplazada por la mía, pero los muchachos con antigüedad se quejaron, mi versión se cayó como una piedra... pero aproximadamente un año después Cambié de trabajo, el CTO del lugar anterior obtuvo mi número de mi antiguo jefe y el CTO llamó personalmente y me preguntó si volvería con un contrato temporal para respaldar mi versión de esa herramienta. Yo estaba interesado, pero no le gustó el precio que puse (mucho menos de lo que sé que gastaron en la versión chatarra) y nunca volvió a llamar.

En mi próximo empleador obtuve la bendición de hacer una versión "ligera" de uno de sus productos. En aproximadamente 2 meses, creé una versión que tenía menos errores, funcionaba mucho más rápido incluso en menos hardware, era más fácil de mantener y actualizar, tenía mejor documentación de arquitectura e incluso comenzó a tener más funciones que la versión original (y algunas funciones incluso querían pasar a la versión completa)... hasta que alguien dijo: "Oye, deberíamos reemplazar la versión completa con esta mejor". Entonces ¡bam! De repente, la versión "lite" fue eliminada. Me pusieron de nuevo en la versión completa, completa con todos sus horribles olores de código (eso es un eufemismo: todo era el pantano del hedor eterno), la falta de documentación y los errores y demás.

La versión completa en realidad fallaba mucho al iniciarse, a veces requería 10 intentos o más antes de que se iniciara correctamente, y la respuesta a eso era no llamar al software directamente, sino crear una secuencia de comandos de inicio que solo intentaba en un bucle infinito. para ponerlo en marcha durante varios minutos. No le importaba al tipo con más antigüedad y su amigo en la gerencia.

A veces simplemente no hay nada que puedas hacer.

Si su compañero es realmente tan denso o terco como sugiere y no está exagerando, es posible que deba abandonar la idea de contar con su apoyo. En ese caso, solo necesita convencer a quien pueda tomar la decisión y dejarlo así.

Si no puede convencer ni a su compañero ni al gerente con el rol de toma de decisiones, entonces es una causa perdida y solo necesita salir de ese proyecto. Con suerte, el empleador es lo suficientemente grande como para que pueda cambiar.

Otra ruta, aunque sigue siendo una especie de proyectos cambiantes, es...

Venda su software como un producto nuevo

No me refiero necesariamente a poner en marcha su propia empresa para competir contra su empleador. Esa es una opción, pero lo que quiero decir es venderles la idea de que su software podría considerarse "Nuestra aplicación 2.0" o llamarlo un software completamente diferente.

Microsoft tiene Internet Explorer y Edge. Tienen Notepad pero también tienen Wordpad y Word, cada uno mejor que el anterior.

Puede vender su software como competidor del software de su par incluso si es la misma empresa que lo hace. Entonces su compañero puede tener su software tal como está, y si nadie lo quiere, entonces su proyecto morirá por sí solo.

Presentar el nuevo sistema.

Organice una presentación técnica de un gran equipo/multiequipo sobre el nuevo sistema. Demostración del proceso de búsqueda de errores utilizando el sistema anterior. Luego haga una demostración para encontrar un error con el nuevo sistema. Lo ideal es usar problemas de ejemplo reales que la administración sepa que son legítimos, no algunos errores pequeños orquestados.

Ver para creer. El desarrollador original tendrá dificultades para defender el antiguo sistema, cuando el nuevo sistema se vea en acción.

Luego proporcione estadísticas que muestren la cantidad de errores encontrados usando el nuevo sistema durante X tiempo.

No golpees el sistema anterior y lo malo que es. Vender sólo el nuevo sistema y lo bueno que es sin ningún tipo de arrogancia, lo cual es importante. Quiere hacer amigos para apoyar el nuevo sistema, no hacer enemigos para resistirlo.

Muestre el tiempo, exija las razones.

Ejecute el código antiguo y el suyo y muestre cuánto tiempo está ahorrando.
Muestre cómo el código antiguo equivaldría a basura cuando se traslada a la nube. Muestre que si deja de funcionar, el tiempo de ejecución será cero. Si deja de funcionar, eso no solo se traduciría en más tiempo/horas de trabajo para arreglarlo, sino que también detendría cualquier "producción".

Hágales saber, hasta el punto de probarlo personalmente, que un sistema antiguo con errores es mucho más vulnerable de explotar.

Básicamente, debe demostrar que el sistema no funciona. Es simplemente "correr". E incluso un pequeño guijarro lo aplastará.

Si es necesario que "ayude" a la gerencia a saber "a quién creer", sugiérale que lea este hilo de control de calidad.

Pero mantenga su currículum actualizado: estoy seguro de que una de las causas de mi despido fue reducir a la mitad el tiempo de compilación y el tamaño del ejecutable mediante un enfoque que un colega "más experimentado" le había dicho a la gerencia que era imposible cuando lo recomendé.

Una de las respuestas ya se acerca a lo que quería decir, pero creo que vale la pena resumirla, así que seré breve.

A los gerentes, especialmente a los gerentes no técnicos, les gustan las figuras. Les gustan los gráficos. Necesitan números concretos que puedan justificar sus decisiones. Esto es todo lo que realmente necesitas para mostrarles.

Reúna un par de diapositivas que muestren (cuando sea posible):

New vs Old deployment time
Frequency of bugs with time
Time to fix bugs 

Cosas de esta naturaleza. Reúna un par de buenas estadísticas, manténgalas breves y ordenadas, muéstrelas a la gerencia y tendrá la garantía de tener su atención si sus contribuciones tienen el impacto que afirma. Esto es realmente todo lo que necesita hacer para convencer a la gerencia. El resto de las respuestas se refieren principalmente a la política de la oficina, que aconsejo evitar en los casos en los que pueda demostrar su punto con números/gráficos sólidos. No se preocupe por el otro desarrollador, una vez que haya convencido a la gerencia, la responsabilidad recae en él para superarse o encontrar otro trabajo.

Perdón por una respuesta tan concisa, pero aquí hay una cosa simple e importante que aprendí de mi experiencia pasada que me temo que te estás perdiendo:

La consistencia es importante