Pregunta:
Apoyar a los desarrolladores que insisten en usar su lenguaje favorito
vavojediha
2019-07-11 22:00:21 UTC
view on stackexchange narkive permalink

Me uní a un equipo de alrededor de cinco desarrolladores que construyen un sitio web basado en microservicios, en una tienda que enfatiza la autonomía y el aprendizaje. Sin embargo, resulta que uno de los desarrolladores está escribiendo "sus" partes en su nuevo idioma favorito, X 0000-.

No nombraré X para evitar discusiones religiosas, sino que enumere por qué estoy preocupado:

  • X es nuevo, relativamente oscuro y parece más dirigido a escribir utilidades de línea de comandos, no API de servicios web
  • está evolucionando rápido, aparentemente Al documentar algún código antiguo, se eliminó alguna funcionalidad básica, no se compilaba en versiones más nuevas, por lo que tardó un par de días en volver a implementarlo.
  • Parece que hay poca técnica anterior sobre cómo abordar una tarea determinada en X. Una próxima solicitud es agregar búsquedas a los puntos finales de la API. No tiene idea de cómo hacerlo, admitió felizmente que cada punto final se implementa de manera diferente y "podría volver a escribir todo". Me gusta su actitud positiva, pero ¿es así realmente cómo abordar el código de producción?
  • Los otros desarrolladores están claramente incómodos con X a pesar de algunos meses de exposición. He visto problemas en el sitio en vivo al implementar código roto cuando él estaba fuera. Sí, se necesita una conversación sobre las pruebas, pero el hecho de que no puedan detectar errores sorprendentes en X es una señal de alerta.
  • Ha comenzado a agregar complementos a otros servicios, "para hacerlos más similares a X". Aún no estoy seguro de lo que eso significa.
  • etc. etc.

Es una persona agradable y accesible. No es arrogante ni discutidor ni nada de eso. Él está realmente, realmente en X, incluyéndolo en cada conversación, incluso con personas sin conocimientos técnicos. Es agradable ver que es un apasionado, pero está al borde de la obsesión.

Soy su nuevo gerente de línea, preocupado tanto por el bajo número de autobús como por la claridad del día a día riesgo de bolsas de X quebradizas y difíciles de entender.

Si bien podría pedirle que deje de usar X, claramente no saldría bien, y de todos modos quiero que mi equipo sea autónomo y feliz, construyéndolos, no apagándolos. Y sí, estoy reservando tiempo para aprender todo lo que pueda. Tal vez vea la luz y pueda ayudarlo de esa manera.

¿Cómo puedo manejar el riesgo del proyecto presentado por X? ¿Es X en sí mismo el problema?

-1
Por lo que vale, creo que es absolutamente ** brillante ** que el idioma no se especifique en esta pregunta, ya que en realidad no es relevante para proporcionar una respuesta.
@ventsyv nombrar el idioma en cuestión haría que las respuestas fueran menos útiles, en lugar de más útiles, mientras que * también * generaría trabajo extra para los moderadores.La única victoria estaría en la mente de las personas que tienen la oportunidad de argumentar a favor / en contra de su propio X querido / odiado personal. Es mejor dejarlo en el anonimato.+1 a la pregunta de esta deliciosa innovación.
¿Le has preguntado a los otros desarrolladores si no les gusta?
Cuando dice que está usando X para resolver "sus partes" de la aplicación, ¿representa esto una capa completa de la aplicación, o son partes y partes de una o más capas?Por ejemplo, si está escribiendo servicios REST en X, ¿están _todos_ sus servicios REST escritos en X, o algunos de ellos están escritos en otros idiomas?
Ahora que esta pregunta tiene una respuesta aceptada y ha atraído algunas buenas respuestas y comentarios, ¿podremos aprender qué idioma es ** X **?
Quince respuestas:
ventsyv
2019-07-11 22:11:21 UTC
view on stackexchange narkive permalink

Le sugiero que plantee la pregunta al equipo para debatirla. Presente sus inquietudes en la próxima reunión del equipo y pregunte qué piensan sobre ellas.

Dado que suenan como preocupaciones válidas, imagino que obtendrás el apoyo de otros desarrolladores.

Asegúrate de que la discusión sea profesional y mantén la mente abierta. Concéntrese en cómo el uso de X afecta al resto del equipo. De esta manera, será menos probable que el desarrollador se ponga a la defensiva y cuando se dé cuenta de cómo su uso de X afecta al resto del equipo, será muy difícil para él simplemente descartar sus preocupaciones.

Los comentarios no son para una discusión extensa;esta conversación se ha [movido al chat] (https://chat.stackexchange.com/rooms/96213/discussion-on-answer-by-ventsyv-supporting-developers-who-insist-on-using-their).
Neo
2019-07-11 22:17:21 UTC
view on stackexchange narkive permalink

¿Cómo puedo manejar el riesgo del proyecto presentado por X?

Para abordar esto, voy a usar sus propias palabras:

está evolucionando rápido / inestable: al documentar un código antiguo, descubrió que se habían eliminado algunas funciones básicas, que no se compilaban en versiones más nuevas, por lo que tardó un par de días en volver a implementarlas

Y

Los otros desarrolladores están claramente incómodos con X a pesar de algunos meses de exposición. He visto problemas en el sitio en vivo al implementar código roto cuando estaba fuera. Sí, se necesita una conversación en torno a las pruebas, pero el hecho de que no puedan detectar errores sorprendentes en X es una señal de alerta

Este lenguaje obviamente no es muy maduro . Construir tu imperio sobre arenas movedizas no es un buen plan, y creo que lo sabes. Como administrador, depende de usted administrar el riesgo y establecer los estándares .

¿Es X en sí mismo el problema?

Creo que el problema puede ser que no hay estándares establecidos en su grupo . Le sugiero que usted y su equipo se pongan de acuerdo sobre qué idiomas se utilizarán y luego sigan adelante.

Cualquier nueva tecnología debe ser presentada al equipo antes de que se utilice en producción . Cuando se presenta una nueva tecnología, el equipo vota sobre la validez de la tecnología. De esta manera, no hay un solo tipo malo en caso de que X sea rechazado.

Además, y esto es realmente importante para usted: debe poder respaldar el código cuando un desarrollador se va. Si permite uno, esto se vuelve más difícil para usted. Es posible que también desee investigar un poco la popularidad y uso de este idioma para asegurarse de que puede contratar ayuda nueva cuando llegue el momento.

Amén a esto.No se puede decir si X es "el problema" o no sin definir qué constituye el éxito.Uno de los equilibrios más importantes en la gestión de una tienda de software es dar a los desarrolladores la libertad de hacer las cosas de la manera * que * consideren mejor, en equilibrio con hacer las cosas que son * mejores para la empresa * en términos de sostenibilidad.Es mejor cuando puede combinar esos dos objetivos, y tener buenos estándares es la forma en que lo logra.
Por cierto, conocer X para una contratación futura y demostrar que está utilizando X es un punto atractivo muy importante para la mayoría de los futuros desarrolladores (los mejores, los que desea contratar).Es por eso que muchas empresas de renombre permiten un pequeño uso de idiomas extraños.Por cierto, la mayoría de las empresas usan [`make`] (https://en.wikipedia.org/wiki/Make_ (software)), pero algunas atractivas usan [ninja] (http://ninja-build.org/)para casi el * mismo * rol.
Convenido.Todas las empresas * exitosas * con las que he trabajado se han estandarizado en lenguajes (y en general estándares de codificación para hacer que el código de todos sea similar).La parte más importante del software no es hacer que haga lo que inicialmente hace, sino asegurarse de que pueda mantenerse razonablemente en el futuro (¡lo cual puede que usted no lo haga!).
@BasileStarynkevitch "conocer X para una contratación futura y demostrar que estás usando X es un punto atractivo muy importante para la mayoría de los futuros desarrolladores (los mejores, los que quieres contratar)" ¡¿Eh ?!No estoy seguro de cómo se puede afirmar eso, sin saber qué es X.En cualquier caso, no creo que conozca a muchos, si acaso, buenos desarrolladores que buscan activamente roles que funcionen con lenguajes extraños y esotéricos.Por lo general, todo lo contrario.
Que los desarrolladores elijan tecnologías es genial y todo, pero solo hasta cierto punto.Y uno de esos puntos es no dejar que cada hombre se ensucie.No solo porque otras personas tendrán que revisar y mantener este código, sino que su personal de administración / operaciones / seguridad preferirá absolutamente no tener otra tecnología para mantener y realizar un seguimiento.
"Para abordar esto, voy a usar tus propias palabras" + "Este idioma obviamente no es muy maduro" - Leí esto y pensé que estabas escribiendo el OP antes de darme cuenta de que el idioma al que te referías era 'X', no su inglés...
Esta es la respuesta con la que más estoy de acuerdo.Estipularía que la autonomía no equivale a una total libertad para tomar todas las decisiones.La empresa, o incluso usted, como director de este equipo, puede y debe tomar decisiones generales generales.Lo que hacen los desarrolladores dentro de ese marco puede ser autónomo, pero si el resultado final es producir algún artículo, ya sea hardware o software, ya sea real o virtual, entonces _cualquier cosa_ que potencialmente interrumpa ese flujo de efectivo será la causa, en el mejor de los casos., despidos y reducción de personal.Siempre, siempre, siempre ... ten en cuenta ese maldito autobús asesino en serie ...
berry120
2019-07-12 00:46:14 UTC
view on stackexchange narkive permalink

Estaría muy, muy preocupado por esto.

Si lo atropella un autobús mañana o decide irse mañana, entonces tienes:

  • Un costo enorme, tanto en tiempo como en dinero, de encontrar un experto en X para reemplazarlo;
  • Un equipo que no comprende nada del código que ha escrito;
  • Un equipo que ni siquiera puede implementar el código que ha escrito;
  • Código que probablemente solo funcione con una versión específica y desconocida de X, y romper con versiones futuras.

Entonces tendrás a tus superiores lloviendo sobre ti como una tonelada de ladrillos preguntándote por qué demonios dejaste que esto sucediera en primer lugar.

Dices que es un buen tipo, demasiado entusiasta, así que le plantearía estos problemas a él y a todo el equipo en general. Pregunte por sus opiniones sobre las soluciones. Enfatice que esto no es un castigo o algo que hayan hecho mal, solo un problema potencial que todos deben resolver. Haga hincapié en que este no es un problema impulsado por idioma , es un problema impulsado por negocios . Asegúrese de estar abierto a las críticas si su comprensión de cualquiera de los puntos anteriores es incorrecta, pero si no es así, debe defender su posición para asegurarse de que:

  • No se escriba ningún código nuevo en X;
  • Preferiblemente, tiene un plan a más largo plazo para migrar el código existente que está escrito en X a otro idioma.

Eso no quiere decir que no deba decisivo para elegir otro lenguaje más adecuado que se pueda usar, y eso no quiere decir que deba abandonar X por completo. Quizás podría organizar talleres o presentaciones donde demuestre nuevos patrones / paradigmas en X, y cómo se pueden aplicar a (lenguaje relevante para el lugar de trabajo). Quizás pueda buscar otro idioma que sea más común, pero que tenga más propiedades de X.

Sin embargo, si yo fuera el líder del equipo, ciertamente no cedería en permitir que ese lenguaje se use en un contexto empresarial crítico.

Tenga en cuenta que el [factor de bus] (https://en.wikipedia.org/wiki/Bus_factor) es una analogía común para una evaluación de riesgo, el usuario no está tratando de ser dramático.
@TravisClark Dato curioso;el enlace que tiene va a una página donde una imagen de Wikimedia descrita como "Un autobús esperando en un paso de peatones en Lima" está titulada "Una persona en peligro de ser atropellada por un autobús".¡Habla de vaso medio vacío / medio lleno!
Solución para una versión específica de X: "compruebe el compilador en el control de código fuente"
R.. GitHub STOP HELPING ICE
2019-07-12 07:30:22 UTC
view on stackexchange narkive permalink

No difícil.

Los idiomas favoritos, o incluso un número excesivo de idiomas, que se introducen en un proyecto hacen que sea completamente imposible de mantener a largo plazo. Cuando el desarrollador se vaya, terminará con el código en su lenguaje favorito en el estado en el que lo dejó, y un montón de soluciones en los otros componentes para hacer las cosas sin tener que cambiar el código que nadie entiende. Hablo por experiencia en proyectos donde esto ha sucedido.

Este equipo / proyecto / empresa obviamente tiene recursos ilimitados o va a morir rápidamente.
200_success
2019-07-12 07:34:40 UTC
view on stackexchange narkive permalink

¡Por supuesto que no! Empresas enteras han muerto porque eligieron el idioma incorrecto para escribir su código base. Si el lenguaje muere, se vuelve impopular o conduce a problemas de escalabilidad intratables, el código también muere. ¿Puede permitirse el lujo de reescribirlo?

Cuando necesite reescribir completamente una pieza de software en un idioma diferente, será un blanco fácil, porque no puede lanzar un nuevo producto hasta que la característica de reescritura se acerque paridad con el producto antiguo. Si es posible evitar una reescritura, ¡debería hacerlo!.

Estudios de caso:

  • Twitter sufrió frecuentes "ballenas fallidas" y, finalmente, reescribió su servidor Ruby on Rails.
  • WordPerfect fue aplastado por Microsoft Word. Si bien hay muchas razones comerciales para su caída, parte de su problema fue que gran parte del código estaba escrito en lenguaje ensamblador, lo que dificultaba la migración a Windows.
  • John Ousterhout , quien inventó el lenguaje Tcl, fundó Ajuba Solutions, una empresa cuyo software estaba escrito principalmente en Tcl. Si bien no había nada técnicamente malo con Tcl, simplemente no era tan popular. Su empresa tenía algunos desarrolladores de Tcl dedicados y talentosos, pero era difícil contratarlos. Finalmente, la empresa fue adquirida, la base de código se abandonó y la mayoría de los desarrolladores perdieron el interés en trabajar después de la adquisición.

Ningún lenguaje de programación sobresale en todo, y usted quiere desarrolladores para poder elegir la herramienta adecuada para el trabajo. Dicho esto, debe haber algunas limitaciones al introducir idiomas en la base de código de su empresa. Algunos criterios a considerar:

  • Su equipo debe dominar el idioma con fluidez para que pueda haber revisiones de código y varios encargados del mantenimiento.
  • Debe poder contratar programadores que estén dispuestos a trabajar en el lenguaje y su ecosistema. (Y debe poder tolerar el tipo de desarrolladores que tienden a gravitar hacia esos lenguajes).
  • El lenguaje debe ser lo suficientemente versátil para que la inversión valga la pena.
  • Debe reconocer y aceptar los riesgos asociados con el lenguaje (por ejemplo, cambios frecuentes incompatibles, vulnerabilidades de seguridad frecuentes, calidad de la biblioteca estándar, escalabilidad , seguridad de la memoria, legibilidad, estrategias de manejo de errores, comportamiento poco intuitivo, etc.)

A veces puede haber factores atenuantes para el riesgo de elegir un idioma más oscuro. Por ejemplo, un lenguaje puede interoperar con otros lenguajes en una máquina virtual Java o Common Language Runtime de Microsoft. O el lenguaje (por ejemplo, Swift) podría estar diseñado para interoperar con otro (Objective-C). La interoperabilidad al menos le brinda una ruta de migración que no lo deja varado durante una reescritura.

Puede considerar otorgar más flexibilidad para el código desechable o el código prototipo. A veces, la capacidad de crear prototipos supera rápidamente las preocupaciones a largo plazo mencionadas anteriormente. Sin embargo, tenga en cuenta que los prototipos pueden tender a convertirse en soluciones permanentes.

En su caso particular, dijo que tiene un sitio web basado en microservicios, con partes del mismo implementadas en otro idioma. Incluso si no está apostando el futuro de su empresa al lenguaje X , mezclar innecesariamente los lenguajes de implementación es perjudicial para construir una arquitectura cohesiva. ( El hecho de que un desarrollador tenga total libertad sobre una parte del proyecto es una señal de alerta sobre la falta de diseño arquitectónico en su empresa. ) Tener que aprender el idioma no es la única barrera; también aumenta la complejidad de las herramientas para el desarrollo, la construcción, el análisis estático, las pruebas y la implementación. Luego, también hay más bibliotecas que necesitará parchear en el futuro. También mencionaste que el lenguaje introduce cambios incompatibles de vez en cuando, lo que indica que se trata de un software de calidad experimental , no de calidad de producción. Si todo el equipo asume estos costos solo por la preferencia personal de un desarrollador, todos van a resentir a ese desarrollador, ya sea en secreto o abiertamente.

En general, la elección del lenguaje de programación (o, para el caso, los marcos de programación) tiene que ser una decisión del equipo , y no debe ser tomada por un solo lobo solitario o un desarrollador estrella de rock. Parece que su equipo no se siente cómodo con el lenguaje X , y el sentimiento del grupo debería ser una buena razón para exigir al desarrollador inconformista que deje de usarlo.

El voto de la mayoría es un buen camino a seguir, creo.Pero aún así, la gente necesita aprender las convenciones de codificación y modismos antes de comenzar con cualquier idioma, y la única forma de asegurarse de que la gente esté escribiendo código idiomático es con revisiones de código.
`Tenga cuidado, sin embargo, que los prototipos pueden tener una tendencia a convertirse en soluciones permanentes. 'Absoluto +1 de mi parte: construí un sistema" prototipo "en VB3 (lo sé, lo sé) para una importante empresa de la ciudad de Londres como pruebade concepto y terminó entrando en producción.4.500 personas lo usaron al final.Todavía me estremezco hasta el día de hoy.
Word se enfocó deliberadamente en WordPerfect inicialmente y tuvo Exchange para aprovechar el paquete de Office.
Abigail
2019-07-11 23:00:01 UTC
view on stackexchange narkive permalink

Esta es una de las pocas cosas en las que creo que un gerente debería poner su pie firme y no ceder. Lo que el desarrollador está haciendo perjudicará a la empresa a largo plazo. Y no importa qué sea X, lo único que importa es que su empresa no tiene mucha experiencia en X, y será difícil atraer experiencia en X.

Su desarrollador se equivoca que X es la solución correcta. No porque sea el lenguaje incorrecto para el proyecto, es el lenguaje incorrecto para la empresa .

Dígale a su desarrollador que sus acciones no son las acciones de un desarrollador senior, e incluso más abajo expectativas para un desarrollador normal. Deje en claro que sus acciones no se reflejarán bien en su próxima revisión de desempeño, y si continúa de esta manera, afectará sus posibilidades de promoción y bonificaciones.

Dígale que espera que los desarrolladores Actúe lo mejor para la empresa y que esté trabajando en un producto que se espera que sea desarrollado y mantenido durante mucho tiempo, y no solo por él. Cada desarrollador actual y futuro debería poder trabajar en el producto, sin tener que aprender primero un idioma diferente. Dígale que espera que un buen desarrollador considere cuál será la situación el próximo año, dentro de cinco y diez años. Y que las decisiones que se tomen hoy influirán en el futuro.

En otras palabras, dígale que deje su orgullo en la puerta y se convierta en un jugador de equipo.

Este tipo de enfoque es extremadamente torpe y puede crear resentimiento en un equipo donde se valora la colaboración, la cooperación y la creatividad.Hay momentos en los que se debe alentar a un empleado a "hacer lo suyo", y momentos en los que es necesario decirle a los empleados que sigan la línea.Dado que esto no iba en contra de las reglas del equipo, un gerente debe adoptar un enfoque más suave.
Como dije en otra parte, esto es trabajo, no escuela Montessori para adultos.Dicho esto, estoy de acuerdo contigo Y con Julie en Austin.Está claro que el desarrollador debe dejar de tratar a X como la respuesta a todos los problemas, pero la forma en que se envía el mensaje es importante.La mano más pesada podría ser necesaria si se niega por completo a hacer su trabajo (es decir, espera que el trabajo sea su campo de juego personal), pero ese no tiene por qué ser el tono inicial.
Esta respuesta es divertida, porque habla de actuar en el mejor interés para la empresa, pero si el OP hablara con el desarrollador de esa manera, es probable que la empresa sufriera.Ser parte de un líder es entrenar a los subordinados en lo que es importante.Si bien la capacidad de mantenimiento puede ser una preocupación obvia para algunos, para otros simplemente no se registra en el radar.
J. Chris Compton
2019-07-12 19:14:20 UTC
view on stackexchange narkive permalink

¿Es X en sí el problema?

No.

X no es el problema ... para cada valor de

Este es un problema de administración. Como nuevo administrador, consiguió uno difícil.

Su problema es que

  1. tiene un programador muy entusiasta al que le gustaría
    redireccionar en un empleado más productivo .
  2. Sospecha que si le dice que no puede usar X , tendrá que reemplazarlo porque se irá.
    Le está contando a personas sin conocimientos de tecnología sobre X, tiene razón (actualmente es religioso para él)

Explique cómo funciona el mundo:

Como nuevo gerente Me encanta dejar que las personas usen lo que les apasiona. En su caso, es X .

El problema es que nos califican mal cuando las cosas se rompen. Esto se refleja mal en todo el equipo .
Algunas veces la construcción se ha roto cuando no estabas aquí. Estoy tratando de aprender X para poder unirme a ustedes. Si bien es interesante, no puedo dedicarle suficiente tiempo en este momento.

¿Cómo podemos mantener X sin hacer que todos se vean mal?

Porque no existe un conjunto establecido de mejores prácticas por lo que hacemos, no podemos estandarizar en un lenguaje tan nuevo como X. Es por eso que hemos tenido problemas con él a pesar de que usted es un experto en él.

Entonces ... ¿cómo abordamos esto? a corto plazo?
¿Hay versiones más estables que se puedan utilizar? ¿Cómo podemos asegurarnos de que nada se rompa y nadie más tenga que detener lo que están haciendo para aprender X×?

Cambiar " la compilación se ha roto "a el problema más obvio causado por la presencia de X .

Dale tiempo para responder. Si no responde con mucho, déjelo volver a su escritorio (repita la pregunta antes de ir para que se concentre en "cómo").

Como acabo de explicar en otra respuesta, la solución para lidiar con un compilador que cambia rápidamente es "verificar el compilador en el control de fuente".
Josiah
2019-07-12 12:15:35 UTC
view on stackexchange narkive permalink

Como han dicho otros, no se debe permitir que esta situación continúe. De hecho, parece que la respuesta fundamental va a ser de la forma "No, lo siento, no puedes usar X". Y está en su derecho de decir eso. El peor de los casos es que este desarrollador se enoja y se cierra. Eso sería triste, pero es su perogativa y su respuesta probablemente aún debería ser "No X".

Además de los problemas ya identificados, un desarrollador va por su cuenta con un lenguaje de mascotas

  • hace imposible la revisión efectiva del código
  • dificulta la interoperabilidad con el trabajo de otros desarrolladores
  • requiere la duplicación de código para todas las utilidades comunes utilizadas por X y no X ( particularmente aquellos que están hechos a medida y no se encuentran en la biblioteca estándar de X)
  • Reduce la cohesión del equipo, particularmente entre las facciones X y no X.

Quizás una respuesta más útil

  • Pregunte qué es lo que es deseable en particular acerca de X. Si es genuino, investigue si algunas de estas ventajas podrían usarse en un lenguaje más estándar. (Te sorprendería saber cuántas características de moda llegan a las nuevas versiones de lenguajes antiguos como C ++ y Java, o al menos obtienen soporte de bibliotecas de terceros)
  • Invita al desarrollador en cuestión a tomar la iniciativa ( aunque no sin supervisión) para desarrollar qué lecciones útiles se pueden aprender de X y transferirlas a las mejores prácticas de Y.
  • Recopile algunos datos para defender su punto. P.ej. puede ser útil poder decir "Ya pasamos el _% del tiempo de desarrollo X simplemente lidiando con la inestabilidad de X, en comparación con el _% en la actualización de cambios en Y" o "La integración y depuración del código X ha reducido el rendimiento de el equipo en general en un _%.
  • Considere si existen causas subyacentes de este problema más allá de las preferencias de idioma. Por ejemplo, si esto revela una cultura de equipo general de desarrolladores aislados que trabajan en funciones aisladas, haga algo al respecto. Puede ser, por ejemplo, que la introducción de la programación por pares podría ayudar a abordar las raíces en lugar de los síntomas.

Como acotación al margen, es posible que la respuesta correcta sea "sí , hagamos la transición para usar X ". Ese no es el caso aquí, de manera muy convincente porque X es pequeño, oscuro, inestable y no se ajusta al problema. Sin embargo, suponga, por ejemplo, que tiene una tienda de Android y tiene un desarrollador que desea pasar de Java a Kotlin, porque Google recomendó la transición de Java a Kotlin y prometió que Kotlin tendrá un mejor soporte en el futuro. que Java. En última instancia, tienen mucha razón.

Se aplican muchas de las mismas preocupaciones. Deberá preocuparse por la capacitación, la compatibilidad del código, la forma en que responden los miembros de su equipo y, posiblemente, incluso el riesgo de que a uno de sus desarrolladores no le guste tanto el cambio que decida abandonar. Mientras tanto, se aplicarían muchas de las mismas mitigaciones: autorizar a las personas interesadas a encabezarlo, recopilar datos sobre por qué se tomó la decisión, escuchar a varias partes interesadas, etc.

Destacaría el concepto de programación en pareja en la respuesta de Josiah.Tener que explicar la sintaxis de X a todo el mundo haría que el desarrollador volviera a los lenguajes conocidos o haría que todo el equipo se entusiasmara con X ..
“Hace imposible la revisión efectiva del código” es una justificación significativa en sí misma.He visto que esto mismo sucedió, y ese desarrollador corrió desenfrenado, porque nadie pudo verificar su trabajo.
En un equipo que “enfatiza la autonomía y el aprendizaje”, ¿tienen revisiones de código (aprendizaje) o no (autonomía)?¿Y es la calidad del desempate (revisiones de código) o divertida (sin revisiones de código)?
Danubian Sailor
2019-07-13 01:36:52 UTC
view on stackexchange narkive permalink

Creo que está abordando el problema desde la perspectiva incorrecta .

Lo está convirtiendo en nuestro lenguaje favorito frente a su problema con el lenguaje de su mascota. Los idiomas son solo herramientas, bastante universales, por lo que su elección es un tema secundario.

El verdadero problema es que tienes un caos total en el equipo . Parece que todos pueden hacer lo que quieran, eligiendo cualquier herramienta, incluso aquellas con las que no está familiarizado. Esto es lo que necesita abordar.

Tener solo una persona en el equipo que pueda apoyar cualquier parte relevante del proyecto es simplemente una locura. O al menos 2 personas en el equipo deben dominar X hasta el extremo que permita el mantenimiento, o X debe irse.

El hecho de que su desarrollador de X-pet no esté seguro de cómo implementar uno de los aspectos cruciales en X significa que ni siquiera él lo domina de manera razonable. Es un momento para pedir perdón, pero su empresa está empleando personas para hacer el trabajo y no para divertirse aprendiendo nuevas herramientas.

Una solución considerable podría ser permitirle desarrollar herramientas / funciones experimentales en, digamos, un 20% de tiempo. Prohibir totalmente a X puede ser contraproducente, si quieres mantener a este tipo en tu equipo (y lo más probable es que lo hagas, ya que un equipo de 5 que se convierte en un equipo de 4 en una aplicación productiva seguramente no ayudará a mantener la aplicación).

cjs
2019-07-13 08:05:29 UTC
view on stackexchange narkive permalink

No, el idioma X en sí mismo no es realmente el problema. Lo que ha descrito aquí son los síntomas de un problema mucho más profundo que afectará también a todos los demás sistemas que su equipo produce: el equipo no está realmente trabajando como un equipo, sino como un grupo de personas desconectadas.

Su instinto de que "quiere que [su] equipo sea autónomo y feliz, construyéndolos, no apagándolos" es correcto; necesita resolver este problema entrenando al equipo para que lo solucione. Comenzaría intentando eliminar la propiedad del código claro que está sucediendo cuando el código escrito en el lenguaje X es "su" código. Es el código del equipo, y el equipo en su conjunto debe ser responsable de mantenerlo y extenderlo.

Puede comenzar con cómo se asignan las historias (o lo que sea su equivalente). Idealmente, todos los miembros del equipo deberían trabajar regularmente en todas las partes del sistema, en lugar de partes específicas del sistema que "pertenecen" a desarrolladores particulares. Está bien si tiene algunos desarrolladores que son expertos en una determinada tecnología o partes del sistema mientras que otros no lo son, pero no debería haber nada en su sistema donde no haya al menos dos desarrolladores que sientan que conocen esa parte lo suficientemente bien como para Sea el líder técnico en cualquier historia en particular donde sea un componente importante.

La programación en pareja y simplemente pedir ayuda son soluciones típicas para difundir el conocimiento. Extreme Programming se encarga de esto al permitir que cualquiera elija y sea el protagonista de una historia, sin importar cuánto o poco sepa sobre ella, y confía en que los desarrolladores no pueden decir "no" a las solicitudes de ayudar con esa historia, permitiendo que el desarrollador, a medida que recibe su ayuda, aprenda todos los detalles sangrientos necesarios para terminar la historia. (La asignación de historias en XP es en realidad una función de gestión de proyectos: el desarrollador que gestiona una historia para esa iteración es responsable de asegurarse de que se realice, de encontrar todos los recursos necesarios para hacerlo. Esto normalmente dará como resultado que el desarrollador tenga una experiencia técnica razonablemente profunda. comprensión de la historia al final de la iteración, ya sea que haya comenzado con eso o no).

Así que explíquele a su equipo que está contento con el uso del lenguaje X , o cualquier otra cosa, si todo el equipo está de acuerdo en que es una buena idea y está de acuerdo en que si el desarrollador en cuestión es secuestrado por extraterrestres, el equipo continuará bien sin él. Entonces depende de ese desarrollador vender sus ideas técnicas dentro del equipo. Deje en claro que incluso si el equipo no acepta que X sea el lenguaje de desarrollo principal para todas las funciones nuevas, esto no significa que no pueda usarse en absoluto; tal vez podría usarse solo en ciertas áreas más pequeñas para probarlo y ganar experiencia con él. Fomente las revisiones periódicas de cómo funciona el lenguaje X donde se utiliza y de subsistemas específicos (ya sea que utilicen el lenguaje X o no) con respecto a qué tan bien están funcionando, qué tipos de problemas suelen surgir y cómo se pueden mitigar.

Daniel R. Collins
2019-07-12 08:45:12 UTC
view on stackexchange narkive permalink

Sobre la base de otras respuestas, acepto que los idiomas / tecnologías que se utilizarán en el proyecto deben ser seleccionados positivamente por el equipo antes de ser utilizados (excepto posiblemente un caso de prueba o prueba de viabilidad, sin ninguna promesa o ruta crítica) utilizado en el propio proyecto).

Me preocupa que eso no se haya hecho, y tratar de traer el tema a discusión con el equipo ahora resultaría en nadie dispuesto a confrontar al programador deshonesto y decir "no" (siguiendo el hecho que incluso el gerente tiene miedo de dar ese paso).

Considere lo siguiente como una posible forma de resolver esto: Tenga una reunión de "reinicio", donde el equipo seleccionará / aprobará conjuntamente las tecnologías que se utilizarán y respaldarán en el proyecto. Actúe como si el proyecto estuviera comenzando de nuevo, no se había seleccionado ningún idioma hasta la fecha y está comenzando desde una pizarra en blanco. Ahora la carga de la prueba está en llegar al "sí" para el nuevo idioma (como debería ser), en lugar del "no" (donde parece estar actualmente).

Dmitry Grigoryev
2019-07-12 14:42:26 UTC
view on stackexchange narkive permalink

Debería dejar claro a los altos mandos y al equipo que X en su estado actual es un problema , porque aparentemente actualmente no se entiende que este sea el caso. Dígales a todos que el equipo necesita al menos dos expertos X, en caso de que uno de ellos se enferme. Solicite una formación en X para todo el equipo. Cada vez que el proyecto se interrumpa debido a una actualización de X incompatible, o un error trivial que no se encontró porque los evaluadores no están familiarizados con X, inicie una discusión sobre cómo prevenir tales contratiempos en el futuro.

O bien la empresa decidirá eliminar X, o decidirá ir con todo y hacer que X sea ampliamente adoptado. En cualquier caso, el problema de que X sea un "lenguaje favorito" desaparecerá.

Y no culpes al desarrollador por "traernos X". Los desarrolladores cercanos y apasionados son excelentes activos para la empresa y excelentes colegas. No es culpa suya que la dirección haya aceptado su idea de adoptar X, que les pareció brillante, sin evaluar los riesgos.

AlexanderM
2019-07-12 00:10:15 UTC
view on stackexchange narkive permalink

Creo que debe conversar con el equipo sobre este idioma. Deje que el desarrollador presente el idioma primero, escuche las ventajas que el idioma puede brindar y las desventajas que tiene el idioma. Plantee sus inquietudes sobre estabilidad, compatibilidad, etc. Eche un vistazo al historial de quién desarrolló el lenguaje (por ejemplo, se sabe que Microsoft elimina las tecnologías que estaban promocionando poco antes del anuncio de eliminación (consulte varias versiones de Windows Phone, Silverlight , etc.)) Anime a otros desarrolladores a dar su opinión.

Si la discusión se vuelve en contra de X y realmente no desea cerrar por completo ese desarrollador o se vengaría, puede tomar la decisión de mantener el lenguaje en un proyecto único y ver cómo va a funcionar. ir y tener una segunda ronda cuando el proyecto esté completo (honestamente, esto es lo que haría sin importar qué (a menos que X sea una basura completa): deje que un pequeño proyecto único se haga completamente en ese idioma y tenga una segunda ronda) .

PD: a veces, algunos lenguajes realmente "extraños" y poco comunes pueden dar una gran ventaja en algunos proyectos: http://www.paulgraham.com/avg.html (artículo tiene casi 20 años, por lo que puede ignorar las tecnologías y los lenguajes, pero pensar más en un concepto)

asmgx
2019-07-15 04:13:23 UTC
view on stackexchange narkive permalink

En la parte superior de las respuestas

Creo que el problema es la confianza.

Su desarrollador confía en usar X y tiene miedo de usar cualquier otro lenguaje en el que no es tan bueno.

Probablemente, un entrenamiento en las capacidades de su lenguaje Y le dará cierta confianza en el uso de Y

SeverityOne
2019-07-15 03:00:15 UTC
view on stackexchange narkive permalink

Considere la posibilidad de que su desarrollador (el que realmente le gusta X) esté en el espectro autista, o al menos tenga rasgos autistas. El enfoque obsesivo en una cosa, hablar de ello todo el tiempo, puede indicar que esta persona tiene algún tipo de condición, lo que le dificulta abordar el asunto de manera objetiva.

La razón por la que digo esto es porque, si este es el caso, es posible que deba manejar el asunto de manera diferente a como lo haría con una persona neurotípica (es decir, "normal"). No significa que dicho desarrollador sea menos apto para el trabajo.

Mi empleador me paga para que escriba el software que vendemos a los clientes. No me pagan para que haga lo que quiera y haga lo que quiera. Me gusta jugar videojuegos, por ejemplo, pero eso no genera dinero.

De manera similar, un lenguaje no establecido como X parece estar causando más problemas de los que está resolviendo. Significa que la productividad y el rendimiento de todo su equipo están en riesgo, debido a un tipo que quiere hacer las cosas de manera diferente.

Si se puede demostrar que el uso de X tiene un efecto positivo neto en la productividad y el rendimiento, quédatelo. De lo contrario, aclare a su desarrollador que necesita separar los pasatiempos (su fascinación por X) del trabajo (lo que paga su salario).

En el trabajo, estoy experimentando una situación algo similar. En mi departamento, hay básicamente dos piezas principales de software que se escribieron hace mucho tiempo y que en realidad no se han actualizado. Modelo de objeto anémico, prácticas de codificación deficientes, tecnologías y marcos anticuados ... La lista continúa.

Y aunque tengo la experiencia y el conocimiento para introducir nuevos conceptos, como el diseño dirigido por dominios, micro servicios y aplicaciones de una sola página, también debo considerar que los otros desarrolladores necesitarán tiempo para ponerse al día. Es un equilibrio delicado que debe lograrse.

Pero al final, debe concentrarse en el bienestar de todo su equipo, no en sus miembros individuales. No puedes hacer felices a todos. Es una empresa, no una democracia. Es imperativo escuchar a las personas, pero es igualmente imperativo tomar una decisión y asegurarse de que todos la respeten. De lo contrario, no sea un líder de equipo.



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 4.0 bajo la que se distribuye.
Loading...