¿Cómo evitar que un empleado tenga a la empresa como rehén?

¿Qué puedo hacer para arreglar esta situación?

Nada, sólo has estado allí unos pocos meses, no es tu papel y no tienes el poder de hacer nada excepto quejarte de ello.

Tus superiores tienen muchos recursos, pero no los han usado en 7 años, así que en este punto sólo estás segundo adivinando sus razones y analizando a un colega en lugar de concentrarte en tus propias responsabilidades y tareas.

Contrata a dos o tres de los desarrolladores más inteligentes que puedas encontrar. Entrégales todo el código. Déjalos que verifiquen que efectivamente tienen todo el código, todo lo que se necesita para ejecutar el software. Hágalos aprender lo que hace el código, documéntelo, refactoréelo, hasta que lleguen al punto en que puedan arreglar los problemas más rápido que el Sr. A. Todo esto obviamente sin ningún conocimiento de A.

En ese punto asegúrese de desconectar al Sr. A completamente de cualquier recurso de la compañía, transfiera el trabajo a sus nuevos desarrolladores, e informe al Sr. A que su empleo ha terminado.

Yo pensaría que con los métodos de desarrollo del Sr. A, la cantidad de trabajo que su código hace es en realidad mucho menos de los siete años que el desarrollo normalmente produciría, y que el código está ofuscado, pero no es realmente difícil, lo que hace el trabajo de los nuevos tipos mucho más fácil.

PS. Debido a algunos comentarios, quiero enfatizar esto de nuevo: El problema no es sólo el dinero, el problema es que el software está mucho menos desarrollado de lo que podría estar, porque A se centra en hacer difícil el desarrollo, no en mejorar el software.

Respuesta corta: Su organización actualmente está en grave peligro de El factor autobús .

Por eso nunca dejas que una persona tenga todo el conocimiento. Es un riesgo enorme. ¿Qué pasaría si esta persona decidiera renunciar, o literalmente fuera atropellada por un autobús? Si la situación es como la describes, entonces toda la compañía se irá. Necesita marcar esto a sus gerentes como un riesgo organizacional, no como un asunto de RRHH.

Empiece a hacer que otras personas conozcan el código, con o sin el Sr. A. Preferiblemente sin él, porque ya lo ha identificado como el asunto.

Recuerde, si el Sr. A no ayuda en esta mitigación de riesgos para su organización, entonces él mismo es un peligro para la organización y necesita ser gestionado. Quítenle su poder para que si realmente es atropellado por un autobús no terminen todos sin salida.

Las otras respuestas son bastante buenas, pero hay una cosa adicional que consideraría:

Mi consejo personal sería considerar empezar a buscar otros lugares para trabajar… si la dirección no ha tomado ninguna medida en 7 años, no estoy seguro de que este sea un lugar en el que te gustaría trabajar a largo plazo. Para mí, esto se lee como una señal de advertencia para otro tipo de problemas en la empresa.

y repitió que toma malas decisiones a propósito para mantener el producto de software inestable, difícil de mantener y solucionar problemas

Entonces, ¿por qué su equipo deja que estas “malas decisiones” pasen la revisión del diseño o la revisión del código? Si no tienes un proceso de revisión de código o incluso un proceso de revisión de diseño, aboga por eso a largo plazo.

Pero hasta entonces, todo lo que necesitas saber está en el artículo del blog de Joel on Software: Haciendo las cosas cuando eres sólo un gruñón

Y tiene una llamada específica para tratar con bozos: FILE BUGS. Per Spolsky:

Como gruñón, tu objetivo es la minimización del daño, también conocido como contención. En algún momento, uno de estos genios pasará dos semanas escribiendo un poco de código tan increíblemente malo que nunca podrá funcionar. Estás tentado a pasar los quince minutos que se necesitan para reescribir la cosa correctamente desde cero. Resiste la tentación. Tienes la oportunidad perfecta para neutralizar a este imbécil durante varios meses. Sólo sigue reportando errores contra su código. No tendrán más remedio que seguir trabajando durante meses hasta que no encuentres más bugs. Esos son meses en los que no pueden hacer ningún daño en ningún otro lugar.

Por lo demás, como nuevo miembro del equipo, tu objetivo debería ser desarrollar tu propia reputación de excelencia.

Sólo para decirlo más claramente que las respuestas actuales…

Tu problema :

nadie sabía cómo arreglarlo.

Tu solución :

• Aprende a arreglarlo tú mismo.

Ya está, ahora la empresa ya no necesita al otro tipo.

Ponga esto en la pared: (Tendrá que cambiar algunos de los nombres y lugares).

Hace algunos años pasé una semana dando un curso de diseño de programas en una empresa de fabricación en el medio oeste de los Estados Unidos. El viernes por la tarde todo había terminado. El director del programa, que había organizado el curso y lo pagaba con su presupuesto, me pidió que fuera a su oficina. “¿Qué te parece?”, preguntó. Me pidió que le dijera mis impresiones sobre su operación y su personal. “Bastante bien”, dije. “Tienes buenas personas allí”. Los cursos de diseño de programas son un trabajo duro; estaba muy cansada; y la consultoría de evaluación del personal se cobra extra. De todos modos, sabía que realmente quería contarme sus propios pensamientos.

“¿Qué piensas de Fred?” preguntó. Todos pensamos que Fred es brillante.“ "Es muy inteligente”, dije. “No le entusiasman los métodos, pero sabe mucho de programación”. “Sí”, dijo el director del DP. Se giró en su silla para enfrentarse a un enorme organigrama pegado a la pared: unas cinco grandes hojas de papel de impresora de línea, tal vez doscientos símbolos, cientos de líneas de conexión. “Fred hizo eso. Es la acumulación de la paga bruta de nuestra nómina semanal. Nadie más que Fred lo entiende.” Su voz se redujo a un silencio reverente. “Fred me dice que no está seguro de entenderlo él mismo.”

“Estupendo”, murmuré respetuosamente. Entendí la imagen claramente. Fred como Frankenstein, Fred el brillante creador del incontrolable diagrama de flujo del monstruo. “¿Pero qué pasa con Jane?” Dije. “Pensé que Jane era muy buena. Ella recogió las ideas de diseño del programa muy rápido.”

“Sí”, dijo el director del DP. “Jane vino a nosotros con una gran reputación. Pensamos que iba a ser tan brillante como Fred. Pero aún no se ha probado a sí misma. Le hemos dado algunos problemas que pensábamos que iban a ser muy difíciles, pero cuando terminó resultó que no eran realmente difíciles en absoluto. La mayoría de ellos resultaron ser bastante simples. Ella no se ha probado a sí misma todavía — si ves lo que quiero decir?”

“Vi lo que quiso decir.”

• Extracto del libro Requerimientos y Especificaciones de Software - Michel Jackson (Bien vale la pena leerlo).

La respuesta es simple: despídelo. Puede que tenga que pagar una cantidad de dinero no trivial a corto plazo para arreglar el desastre que ha hecho, pero el Sr. A no es más listo que nadie en el mundo - alguien más podrá mantener el software a corto plazo, y mejorarlo a largo plazo.

Hay una perspectiva a considerar.

A la compañía le gusta así. Si no lo hicieron 7 años es mucho tiempo para dejar que persista.

Tendemos a olvidar como desarrolladores, que no es nuestro trabajo escribir código bueno o inteligente. Es nuestro trabajo hacer que un producto exista. Escribir buen código sólo hace que el proceso sea mejor, pero puedes tener un producto totalmente asombroso con un código totalmente basura.

La compañía ha respaldado sus decisiones, e incluso lo ha contratado de nuevo. Les “gusta” él y su forma de hacer las cosas. No es probable que cambie esto, incluso si de alguna manera se las arregló para que lo despidieran. Lo que es probable que ocurra es que elijan a una nueva persona para ser “el tipo” y el proceso comience de nuevo.

No es tu trabajo dirigir la compañía. La compañía ha hecho su elección. Tú tienes que hacer la tuya. Aprende del tipo (ha tenido el mismo trabajo durante 7 años, debe estar haciendo algo bien) o sigue adelante.

Para bien o para mal, ni nada ni nadie es irremplazable. (algunos pueden ser más que otros, pero aún así ) Si la gente conoce la solución, pueden empezar a hacer ingeniería inversa.

Estuve en tu lugar más de un par de veces en el pasado. En la situación más parecida a la suya, “Mr. A” se había ido hace mucho tiempo, sin embargo, yo tenía una solución monolítica trabajando para la parte trasera de una compañía de cable donde no tenía el código fuente de las librerías locales desarrolladas, y para colmo era un novato en esa industria.

La ataqué más o menos con un enfoque modular, echando un vistazo al código existente, haciendo ingeniería inversa donde faltaba y escribiendo módulos que reemplazaban a su vez con mejor funcionalidad y velocidad de las tareas principales. Perfeccioné cada módulo antes de pasar al siguiente. En unos pocos meses había matado la aplicación anterior.

Ser irremplazable es exagerado.

Tratar también con cosas heredadas no es una tarea fácil, tal vez tu compañero de trabajo lo hace por inercia o porque no sabe nada mejor.

Desde una perspectiva de negocios, hay básicamente dos soluciones:

1. Transición incremental, es decir, tomar una pequeña parte de la funcionalidad, reimplementarla a un alto nivel, y ponerla en producción, y continuar haciendo esto pieza por pieza hasta que el viejo sistema pueda ser totalmente desmantelado.
2. Construir completamente un nuevo sistema, y luego hacer la transición a él, ya sea de una sola vez o gradualmente, por ejemplo, comenzar nuevos clientes en él y gradualmente mover los viejos clientes a él. El nuevo sistema no tiene que ser tan característico como el antiguo inicialmente; su punto de venta puede ser un precio más bajo, un soporte más rápido, etc.

Las ventajas de la opción 1 son que no necesita una gran cantidad de inversión inicial, su nuevo código se prueba en el campo gradualmente en lugar de todo a la vez, y se empiezan a ver los beneficios tempranamente (porque el negocio gasta menos tiempo y dinero en mantener las partes del antiguo sistema que ya no están activas).

Sin embargo, las desventajas son que la estructura del nuevo sistema puede estar fuertemente influenciada por la estructura del sistema antiguo, y en algunos casos es realmente difícil reemplazar partes de un sistema muy desordenado. A veces es necesario un poco de creatividad, si todo lo demás falla, tu nuevo código puede simular pulsaciones de teclas y clicks de botones en el viejo sistema! Pero interactuar con el viejo sistema puede generar tanto trabajo que es mejor ir con la opción 2.

De cualquier manera, hay es algo que se puede hacer. La pregunta es, ¿cuánto costará y cuánto se ahorrará? Tratar de estimar eso para cada una de las opciones anteriores ayudará a determinar qué opción elegir (si es que hay alguna). Dependerá de los requisitos funcionales, la estructura del sistema existente y la voluntad de la empresa de gastar dinero/utilizar el crédito por adelantado para futuros ahorros.

Como miembro del equipo de software tu trabajo no es dirigir la empresa y sus empleados.

Tu trabajo es escribir buen software. Así que preocúpate por el software, no por las personas.

Ves los problemas con el software, y por tu pregunta, parece que tienes algunas ideas para solucionar los problemas. Lleva estas ideas a tu gerente y lucha por ellas.

“Gerente, este software no está probado y su implementación actual no es comprobable. Sugiero que trabajemos en la reimplementación en un lenguaje que sea más comprobable, usando patrones de diseño que permitan una prueba más fácil”

Es muy probable que:

A. Se trata de una gran empresa en la que la compañía no está dispuesta a invertir, porque no ven la necesidad

B. El Sr. A argumentará en contra de estas cosas y se le escuchará ya que es más veterano

Si eso sucede, entonces usted trató de hacer bien su trabajo y fue sofocado. Es hora de buscar un nuevo trabajo.

Si esto sale bien y te escuchan, te has apuntado a un montón de trabajo.

No puedes asumir la intención detrás de la situación.

Mantenido a propósito lejos de los marcos modernos de desarrollo de software

Podría estar más cómodo con lo que conoce mejor?

Trabajé en grandes compañías cuyo conducto era un mosaico de código antiguo y totalmente nuevo y donde ciertas piezas de código “sólo funcionaban” y nunca se tocaban. Además, los programadores que lo escribieron se habían ido hace mucho tiempo y nadie entendía realmente cómo funcionaban, así que sólo añadían nuevas funciones para adaptarse a los cambios en los requisitos. Su tubería siempre estaba activa, por lo que cualquier lanzamiento importante podría tener consecuencias desastrosas (es decir, trabajo muy caro e interrupción de la entrega), por lo que evitaban tocarla demasiado.

Es un mal hábito y hace que la infraestructura no esté optimizada, pero en realidad tiene su mérito.

Lo que podrías hacer, especialmente si vas a trabajar en mucho o en todo el código: Si no hay documentación adecuada, proponga crear una (si sabe que está cualificado y tiene tiempo) o pregunte si debería hacerse una para acelerar el trabajo.

Debería (como ya lo hace) hablar sobre la adaptación de nuevas tecnologías o mejoras con su gestor pero espere que no salga nada, aunque esté de acuerdo con usted.

Lo más probable es que nadie más arriba vea el beneficio de gastar recursos en esto y su intento podría verse como ah, la sangre nueva piensa que puede cambiar el mundo y enseñarnos sobre el error de nuestros caminos.

Desafortunadamente las estructuras de las empresas se resisten a los cambios repentinos y las modernizaciones son cuestión de desgastar gradualmente la resistencia o implementarla poco a poco a menos que pueda demostrar que “los cambios revolucionarios traerán una edad de oro de beneficios financieros sin riesgos”.

Aunque lo haga maliciosamente para mantener su trabajo, no veo que sea su responsabilidad el destaparlo, especialmente si su superior inmediato está informado de ello.

¿Qué haría usted? ¿Hablar con su gerente o sin él con la dirección superior o con el colega en cuestión?

Como su gerente decidió no seguir con el asunto, probablemente no querrá hablar con sus supervisores con o sin usted, o ya lo hizo y se encontró con un bloqueo allí.

Si habla con sus supervisores sin él, se arriesga a alienarle.

Hablar con el colega seguramente creará un muy mal ambiente de trabajo después y seguramente negará cualquier acusación.

La única forma de arreglar esto es quitarle el control al Sr. A.

Primero obtener la aprobación de la dirección.

Hacer un nuevo git.

1. Importar un buen punto de partida acordado.

2. Empieza desde ahí, y trae el código adelante.

3. No le des acceso al Sr. A en absoluto (ni siquiera le digas que existe)

4. Portar al Sr. A. a su propio repo, o reescribirlo.

5. Dejar que el Sr. A. haga lo que quiera con su repo, ya que no lo usará.

6. 1. Haga cambios falsos en el código para que parezca activo si es necesario para ocultarle su nuevo repo.

7. Eventualmente el código divergirá lo suficiente como para que se vuelva automáticamente obsoleto.

Necesita tomar una decisión crítica para mantener o abandonar la estrategia de los módulos. Los módulos no son necesariamente malos, necesita mantenerlos sincronizados y en funcionamiento.

Esto va a ser mucho trabajo ya que tiene que reescribir mucho código existente.

Un beneficio adicional, es que el código eventualmente divergirá lo suficiente como para que ya no pueda reclamar su código. Será completamente extraño para él.

Tenga en cuenta que como no-gerente, este no TIENE que ser su problema a resolver (aparte de seguir las instrucciones para hacer las cosas que se han decidido como parte de una solución).

También, nunca interprete a ciegas “Queremos el problema XY resuelto” en una declaración “… debido al problema XY”.

También sea consciente de que una vez que impulse cualquier iniciativa, incluso con aprobación, para cambiar la situación, se está involucrando en la política de la empresa. En la política de la empresa, no existe tal cosa como “un innovador inocente sin una agenda personal, que no podemos hacernos responsables de las consecuencias no deseadas”.

Si lo haces, hazlo con una agenda personal, y asume las consecuencias de cualquier manera.

@MightyPizza - Estás perdiendo el tiempo. Ve a trabajar para otra compañía que tenga un futuro mejor y más brillante. Sólo deberías gastar tanta energía en resolver este problema si esta compañía es tu última parada.

Esta es la mejor respuesta que vas a obtener. Prepárate para el salto.

“Quiero hacer el software moderno, mantenible y estable”

La mejor manera de hacer esto es en el Día Uno, primera línea de código, no con la pila caliente de basura de alguien más.

Para él haber permanecido en la posición por tanto tiempo muestra que el negocio está aplicando consciente o inconscientemente La navaja de Hanlon :

Nunca atribuyas a la malicia lo que se explica adecuadamente por la estupidez.

Parece que es muy difícil encontrar casos reales de malicia, sólo cosas que no han funcionado tan bien con el tiempo. De hecho, parece que el Sr. A ha dejado que la gente intente cambiar las cosas y luego las ha arreglado heroicamente cuando han salido mal.

También hay que tener en cuenta que el Sr. A puede estar sufriendo el efecto Dunning-Kruger, en el sentido de que es incapaz de ver que lo que está haciendo está mal.

Podría ser que una vez fue bueno, pero dejó de aprender y dejó de intentarlo. Quién sabe. Lo que hay que tomar como primer principio, es que no importa cuán exasperante sea, hay que tratar con él como si no fuera un agente malicioso.

Su pregunta parece tomar la suposición de que él sólo busca la seguridad en el trabajo y se niega a actualizar las cosas para incrustar esto. Puede que tengas razón, pero no puedes tratar con él sobre esta base.

Estoy seguro de que algunas de tus brillantes ideas se resisten a “lo intentamos una vez y no funcionó debido a X”. Desde una perspectiva de negocios esto tiene sentido, se arriesgaron a que algo no funcionara así que por qué deberían intentarlo de nuevo.

Declaras como tu objetivo.

Quiero hacer el software moderno, mantenible y estable.

Desglosemos esto por necesidad de negocio

1. Moderno

No hay ningún valor comercial implícito en lo moderno. Es discutible en cualquier caso. Tú dices Java 8, otros dirían que Rust o Golag son modernos. Mientras un sistema esté soportado no hay un gran valor en su actualización.

2. Mantenible

Esto también podría ser difícil de argumentar. El Sr. A argumentará que es mantenible, como él lo mantiene. Tendría que argumentar que el costo de mantenimiento bajaría drásticamente para justificar un cambio total del marco.

3. Estable

Usted dice que quiere hacer el sistema HA, pero también dice que

el software monitorea los eventos, hace algún procesamiento sobre ellos y luego toma las acciones apropiadas.

Lo cual no suena como que necesita HA.

¿Y qué hacer?

Tu sistema suena como una gran bola de barro definido por

Una Gran Bola de Barro es una jungla de código de espaguetis, desordenada, descuidada, con cinta adhesiva y alambre de balas. Estos sistemas muestran signos inequívocos de crecimiento desordenado, y de repetidas y oportunas reparaciones.

Afrontar esto de frente, con un desarrollador no cooperativo manejándolo será muy frustrante, y probablemente infructuoso. Suena como si muchos otros lo hubieran intentado y fallado.

Lo que puedes hacer es empezar a evitarlo:

• Si no puedes hacer el sistema HA, entonces usa un sistema de bus de mensajes o algo así para capturar los mensajes de manera que si el sistema se cae no pierdas datos.
• Si no puedes escribir pruebas de unidad, escribe pruebas de sistema. Estas no son tan claras pero permitirán que se hagan pruebas en el sistema
• La próxima vez que se requiera alguna acción, comienza a construir un subsistema independiente que pueda escuchar el bus de mensajes y realizar su propia acción.
• Si puedes empezar a afectar algunos efectos posteriores (por ejemplo encapsulando las acciones que se toman) entonces ponlos en un subsistema.

Hay algún argumento para apoyar el monolito mayoritario sobre microservicios , pero asume que el monolito está bien diseñado. En su caso, el sistema puede estar bien como un monolito bien diseñado, pero si no está bien diseñado, necesita dividir las cosas. Este parece un buen artículo para empezar:

Un enfoque más común es empezar con un monolito y gradualmente pelar los microservicios en los bordes. Este enfoque puede dejar un monolito sustancial en el corazón de la arquitectura de los microservicios, pero la mayoría de los nuevos desarrollos ocurren en los microservicios mientras que el monolito está relativamente quieto.

Sin embargo, es importante seguirle la corriente al Sr. A, no le diga que está reemplazando el sistema, sino que está “mejorando la fiabilidad” o añadiendo redundancia. Si atacas lo que él ha hecho, te hará más difícil alcanzar tus objetivos.

Puede que te den la impresión de que estás haciendo el sistema más complejo. Es cierto, pero necesario si quieres avanzar a largo plazo.

¿Por qué todo el mundo quiere despedir al Sr. A tanto? Creo que no hizo nada malo aquí. El desarrollo de software no se trata de hacer cosas nuevas usando herramientas geniales, o un marco de trabajo. Se trata de hacer una cosa estable que simplemente “funcione”. Su compañía ama al Sr. A y está satisfecha con su trabajo.

Se mantiene alejado a propósito de los marcos de desarrollo de software modernos

Su sistema está actualizado en condiciones estables, entonces ¿por qué el equipo necesita usar un marco de desarrollo de software moderno como Scrum o ágil?

La lógica central del negocio está escrita en lenguajes que no pueden ser probados

¿Existe un requisito de que la lógica central del negocio tiene que ser probada automáticamente?

Reestructurar los componentes de software en 30 módulos para añadir complejidad y problemas de certificación de versiones

¿Cuánto más le costó a su empresa esta implementación?

Diseñarla de forma no escalable, asegurando que no hay capacidades de HA (alta disponibilidad)

La misma pregunta - ¿cuánto más le costó a su empresa esta implementación?

En mi opinión, todo lo que usted escribe aquí es sólo su queja contra él. Si él hizo un montón de cosas “terribles” el sistema en sí se habría fundido en el primer año, y no podría haber permanecido tanto tiempo en su empresa.

Simple, el negocio tiene que ofrecerle un generoso aumento para documentar el estado actual del software y todo el conocimiento que no está siendo documentado entonces lo despiden. O alternativamente, contratan a una empresa de consultoría tecnológica para documentar todo y él verá lo que está escrito en la pared y eventualmente se irá.