¿Cómo desarmas a un codificador de vaqueros? [cerrado]

Encontré una pregunta (código cowboy en el equipo), pero estaba más relacionada con "Ninja Coder" que con el problema que tengo.

Tengo un miembro del equipo que es un ejemplo vivo puro de " Cowboy Coder ". Entiendo que uno no puede cambiar a las personas, pero ¿es una forma de hacer que deje de comportarse como un "Codificador Cowboy"?

Se niega a escuchar al equipo, y recientemente detuvo las revisiones de códigos, las pruebas unitarias, compartió los detalles de implementación, etc.

Sí, él "codifica" rápidamente, pero su código es solo un generador de errores. Otros miembros del equipo y yo estamos en una "fase de corrección de errores" y el 80% de los errores proviene de su código. No quiero arreglar sus errores. Y la gerencia es ciega, o no quiere ver esto, o tal vez les gusta su "velocidad".

¿Hay alguna manera de que yo (como su colega más joven por edad, no su jefe) pueda hacer algo al respecto?

¿Cómo puedo desarmar a este codificador de vaqueros?

Siento que soy el último a quien realmente le importa el proyecto.

Veo algunas opciones:

• Acércate al codificador con tus preocupaciones. Debe hacerse como una crítica constructiva con puntos específicos. Antes de tomar medidas más importantes, es apropiado plantear inquietudes directamente y en privado para darle a la persona la oportunidad de cambiar.
• Reúna información y estadísticas y llévelas a la gerencia. Puede parecer que a la administración no le importa, pero a menudo es importante hacer el esfuerzo de todos modos en caso de que funcione. Las posibles consecuencias negativas incluyen enajenar a otros que no aprecian las quejas a la gerencia.
• Encuentra un compañero del codificador de vaqueros y discútelo en privado. Él / ella podría tener una mejor oportunidad de lograr que la persona escuche.
• Pide trabajar en otro equipo. No resolverá el problema, pero mantendrá la cordura. Por lo menos, siempre trabaja lo mejor que puedas y no dejes que te arrastre.
• Abandone la organización si nadie escuchará. Suena como un mal ambiente.

Se niega a escuchar al equipo, y recientemente detuvo las revisiones de códigos, las pruebas unitarias, compartió los detalles de implementación ...

Las revisiones de código no necesariamente requieren que el codificador envíe el trabajo para su revisión.

Una manera fácil de realizar un seguimiento de lo que hace es vigilar el historial de VCS, buscando sus registros. Si le preocupa su código, esta es una manera fácil de encontrarlo. Obtenga un historial de diferencias, mire lo que él puso y vea si alguna bandera roja salta hacia usted. Capture sus registros lo suficientemente rápido y si encuentra un problema, puede revertir la confirmación y enviarle un correo electrónico a tal efecto. Se le permite llamar a sus compañeros de equipo, incluso como un codificador junior, cuando ve algo obviamente mal.

Sí, él "codifica" rápidamente, pero su código es solo un generador de errores. Otros miembros del equipo y yo estamos en una "fase de corrección de errores" y el 80% de los errores proviene de su código. No quiero arreglar sus errores. Y la gerencia es ciega, o no quiere ver esto, o tal vez les gusta su "velocidad".

El código proviene de los requisitos. Los requisitos dan como resultado pruebas ejecutables que verifican que se hayan cumplido los requisitos. Esas pruebas pueden desglosarse aún más, y pueden escribirse antes de que se realicen cambios para verificar que los cambios cumplan con los requisitos (refactor rojo-verde; la esencia de TDD).

Agregue una métrica de "cobertura de código" al servidor de compilación de su equipo (esperemos que tenga uno; si no, ese es su primer problema). Simplemente verificando que las pruebas unitarias pasadas no detectarán los problemas con su nuevo código no TDD, hecho en áreas que no tienen pruebas unitarias. Después de ejecutar todas las pruebas unitarias, el servidor de compilación idealmente debería haber ejecutado cada línea de código, pero realmente hay algunas cosas que simplemente no puede probar unitariamente. Siendo realistas, aún debería poder esperar una cobertura del 95% o mejor (o excluir ciertas bibliotecas o tipos de archivos de la cobertura). Tarde o temprano, su vaquero registrará algo que rompe la construcción porque ha bajado el nivel de cobertura por debajo del umbral, y usted lo llama.

Y en lo que respecta a la "velocidad", la velocidad es la rapidez con la que se "hacen" las cosas, y no se "hacen" hasta que se hacen correctamente. Puede ponérselo a sus gerentes de esta manera; considere a un mecánico de automóviles que, cuando el gerente toma su BMW para obtener un cambio de aceite, se olvida de volver a enchufar el cárter de aceite y, como resultado, todo el aceite nuevo se derrama antes de que incluso salga del garaje. Claro, el cambio de aceite solo tomó cinco minutos, pero el gerente no se preocupará por eso cuando el motor de su automóvil se detenga en el camino a casa. Le importará que el mecánico haya fallado un paso, eso le va a costar mucho tiempo y dinero adicionales para arreglarlo. En este momento, le está pagando a un vaquero para que haga el trabajo muy rápido, y luego ' s pagarle al resto del equipo una suma mucho mayor para entrar y volver a hacer el trabajo correctamente. ¿Cuál es realmente la ventaja de seguir dejando que el vaquero haga lo suyo?

¿Hay alguna manera de que yo (como su colega más joven por edad, no su jefe) pueda hacer algo al respecto?

Llámalo. Cuando encuentre algo que él arruinó, muéstrele cómo está fallando su código, cómo pudo haber evitado el problema en primer lugar (incluido el diseño adecuado, TDD, revisiones de código) y lo que fue o deberá hacer como resultado para arreglar su código roto.

Siento que soy el último a quien realmente le importa el proyecto.

klaxons a todo volumen, luces intermitentes, sirenas sonando : si realmente sientes que eres la única persona a la que le importa la calidad del código producido por el equipo, entonces hay un problema GRAVE. Si sientes que estás tratando de arrastrar a todo el equipo pateando y gritando a la era de la buena codificación, y es demasiado peso para transportar, entonces déjalo caer. Si hay otro equipo en la compañía que lo está haciendo bien, solicite una transferencia, de lo contrario salga de allí.

Vaya a la administración con sus estadísticas sobre cuántos errores / problemas provienen de este desarrollador. Explíqueles que corregir sus errores afecta la productividad de su equipo. Si, de hecho, el 80% de los problemas provienen de una persona, eso definitivamente debe abordarse. Siempre y cuando se lo explique a la gerencia en términos con los que puedan estar de acuerdo (es decir, "el tiempo perdido es dinero perdido"), intervendrán.

Además, este desarrollador debe solucionar sus propios errores / problemas, por lo que puede ser útil asignarles estos problemas. Su equipo no debería estar cubriendo a esta persona.

¿Hay alguna manera de que yo (como su colega más joven por edad, no su jefe) pueda hacer algo al respecto?

La presión de grupo y liderar con el ejemplo son las únicas buenas maneras. Las mejores formas son hechas por su jefe / líder. Si no eres su jefe / líder, habla con los que sí lo son. Pero al final es su trabajo cuidarlo, no el tuyo. Asegúrese de que está haciendo un buen trabajo y que las cosas tienden a resolverse por sí mismas.

Se niega a escuchar al equipo, y recientemente detuvo las revisiones de códigos, las pruebas unitarias, compartió los detalles de implementación ...

¿No tiene una ruta documentada para el código a través de la revisión, prueba e implementación? Si no, tienes un problema más amplio. Si lo hace, entonces esto es algo que necesita ser escalado.