2018-04-26 08:23:44 +0000 2018-04-26 08:23:44 +0000
185
185

¿Cómo hablarle a la gerencia sobre el código de "genio"?

EDIT:

Gracias a todos por el gran consejo, comentarios y retroalimentación.

Resulta que nadie era el “malo” en esta situación. El consejo que recibí aquí me ayudó a volver a contactar con el anterior líder del proyecto. Resulta que mi compañía, sin razón aparente, había recibido una versión temprana “en desarrollo” de la base de código. La antigua compañía nos envió una versión lista para producción, y, como guinda del pastel, me elogió públicamente por hacer ingeniería inversa de forma efectiva en un producto incompleto hasta la profundidad que tenía.

TL;DR

Heredé un proyecto. En resumen, el código que se me ha encargado mantener es malo. Tan malo, de hecho, que el producto no sólo está incompleto sino que no funciona y lo ha estado durante años.

**_¿Cómo le comunico a la gerencia, de una manera que no les resulte embarazoso, de una manera que no me haga parecer perezoso o estúpido, que un producto valioso se encuentra en un estado lamentable? Aclaración: esta pregunta contra la deuda técnica

**_Esta pregunta tiene que ver con que yo desafíe las creencias de larga data sobre un producto sin cometer un suicidio profesional.

En lugar de tratar estrictamente sobre la deuda técnica, hay esto: la gerencia sugiere que tal vez el código es tan complejo que no puedo entenderlo, y posiciono los errores son por diseño; ** que el desarrollador original es tan meta, que lo que parecen errores son en realidad golpes de genio. Quizás otra razón por la que no se trata de una deuda técnica es que la diferencia entre el código “genio” y la deuda técnica es que la administración comunica que no debo alterar el código “genio”, y que el código “genio” no es una deuda técnica: es la magia negra secreta. **Desearía que la gerencia pensara en ello como una deuda técnica. En cambio no lo hacen. La gerencia no está preocupada por el tiempo, el costo o el dinero directamente – aunque eso es algo preocupante.

  • *

Detalles

La mayoría de las veces, no me pondría nervioso comunicando esto a la gerencia. Desafortunadamente una larga línea de mantenimiento a destajo por personas, algunas de las cuales tenían poca experiencia en desarrollo, que sólo “tocaron” el código lo suficiente como para añadir un parche aquí o allá, y luego seguir adelante, ha pintado un cuadro a la gerencia a lo largo de los años que el proyecto está sólo a un paso de estar listo para la producción.

Ese no es lamentablemente el caso. Una corta lista de temas en el código genio que he encontrado en la base de código de ~1.5Gb son…

  • Hay la misma función, los mismos nombres de variables del mismo alcance en toda la base de código (en un lenguaje que no soporta eso).
  • Las funciones son definidas pero nunca llamadas.
  • Uso e inicialización de variables fuera de servicio.
  • Versiones incompatibles de las librerías usadas.
  • URIs y direcciones IP codificadas sin documentación de lo que hacen.
  • Rutas API solicitadas al azar que no devuelven nada o galimatías; que luego no se usan.
  • Contraseñas no cifradas de código duro y claves privadas ssh.

Debería añadir que cuando empecé a trabajar en ello, **_ni siquiera compiló. Y cuando conseguí compilarlo, falló en tiempo de ejecución.

Es una pesadilla.

El problema es que la dirección ha recibido la garantía de quien lo heredó, y de anteriores desarrolladores “gung-ho”, de que “funciona”, así que han invertido significativamente en él… Y ahora la responsabilidad se me ha pasado a mí. Y lo quieren en producción en unos 2 meses.

Cuando sugiero que los desarrolladores anteriores pueden no haber sido totalmente honestos o no haber entendido el producto completamente, la dirección envía señales mixtas sobre “sólo hazlo”, y “por qué no está hecho todavía” … y “no estamos realmente seguros de que haya funcionado” a “estaba funcionando cuando lo recibiste”, y “nunca lo hemos visto funcionar” a “ya está en producción”.

[EDITAR: pegó la mayor parte del siguiente párrafo en la sección TL;DR.

La gerencia también sugirió que tal vez es tan complejo que no puedo entenderlo, y puso que los errores son por diseño; ** que el desarrollador original es tan meta, que lo que parecen errores son en realidad golpes de genio._** Concedido, no soy un genio, y tal vez ese es el caso: a lo que ofrezco mis observaciones previas sobre los temas fundamentales que encontré.

Tal vez hay política en juego por encima de mi nivel.

Respuestas (1)

0
0
0
2018-04-27 17:55:09 +0000

Su plan de alto nivel debería ser el siguiente:

  1. Arquitecto un camino a seguir. (*)
  2. Estimar cuánto tiempo tomará implementar su “camino a seguir”.
  3. Reunirse con las partes interesadas del negocio y comunicar lo siguiente:
  4. Que no puede compilar/ejecutar el código actual (si eso sigue siendo cierto).
  5. Que le tomará “X” días/semanas para rehabilitar la base de código en un estado compilable/construible/ejecutable.
  6. Que hay un trabajo adicional, más allá de hacer el código compilable, que debe hacer para hacer el código soportable y extensible.
  7. Que le tomará “X” meses para implementar su camino hacia adelante. Luego explique su camino a seguir.(*\N)

(\N) Esto es muy importante porque tendrá que persuadir a las partes interesadas no técnicas y empresariales de que su plan es sólido, factible y que vale la pena.

(\N) Esta es mi recomendación para un camino a seguir, que puede comenzar inmediatamente después de que pueda compilar, construir y ejecutar el código.

  1. Crear pruebas de unidades automatizadas.
  2. Las pruebas de unidad demostrarán que entiendes el código.
  3. Las estadísticas de cobertura del código le recordarán continuamente qué partes de la base del código entiende y qué partes debe probar.
  4. No dejes que nadie se fusione con la rama maestra sin una solicitud de extracción que haya sido aprobada por al menos dos personas.
  5. Las peticiones de extracción socializarán el entendimiento evolutivo de su equipo de la base de código. Fomentar una cultura de apoyo, especialmente en este momento difícil, entre sus desarrolladores. Intenta no perder la calma. Otros desarrolladores sentirán su frustración y podrían frustrarse. Cuando un desarrollador tenga dificultades con algún código difícil, heredado, anime a otros desarrolladores a que le echen una mano, y aborden juntos el código difícil, quizás con la programación por parejas.