¿Una orden de la empresa para cambiar a un determinado IDE es una bandera roja? [cerrado]

"Las órdenes ahora, sin discusión , han llegado a la conclusión de que todos deben cambiar a Eclipse".

Creo que este es la bandera roja real. ¿Su equipo es el experto en desarrollo de software y el que se verá afectado por la decisión y, sin embargo, no llegó a decir una palabra en la discusión que resultó en este orden?

Suena como un manejo excesivo por parte de jefes de pelo puntiagudo. ¿La persona / equipo que toma la decisión tiene una perspectiva relevante para esa decisión?

Dado que los tomadores de decisiones están lo suficientemente calificados para tomar una decisión de este tipo, no pedir la opinión del equipo de desarrollo tiene al menos dos deficiencias:

• El equipo no se siente involucrado. Involucrar al equipo debe ser una prioridad para la gerencia. No me gustaría trabajar como un desarrollador en algún lugar donde mi opinión sobre temas tan centrales como el IDE no sea lo suficientemente valiosa como para que me la pidan. Concedido que pedir la opinión de alguien y luego decidir en contra de ella puede ser peor, pero en ese caso esperaría una razón sólida para esa decisión.

• La administración, sin embargo experimentada, no funciona al 100% con el desarrollo de este código específico. Suponiendo que las personas que no tienen una visión interesante en absoluto serían ingenuas. Por supuesto, puede ser que los gerentes hayan pensado en todo lo que se les ocurrió a los desarrolladores, pero la única forma de saber es preguntar.

Es razonable que cuando trabajen juntos en un proyecto común, que en cada estación de trabajo tengan todas las herramientas disponibles para editar / compilar / depurar su software, y que se conozcan las herramientas principales para realizar aproximadamente el 90% del desarrollo. a todos en el equipo. Ese objetivo es más difícil de lograr si su equipo está creciendo y todos usan su conjunto de herramientas personal favorito: cuanta más gente, más opiniones. Y el trabajo administrativo también se vuelve más fácil si no permite que la cantidad de herramientas crezca más de lo necesario.

Por supuesto, si un desarrollador insiste en usar su editor favorito personal, eso puede estar bien siempre y cuando pueda asegurarse de que la fuente no se vea o se comporte de manera diferente en el editor principal del equipo (en su caso Eclipse), por lo tanto, si el desarrollador B tiene que editar la fuente del desarrollador A, el desarrollador B no debe ser forzado a aprender el editor personal favorito de A para poder cambiar la fuente de manera efectiva. Pero tenga cuidado, si los dos tienen que trabajar juntos de vez en cuando frente a la misma pantalla (o hacer un par de programación), las cosas suelen ser más fáciles si el editor elegido es conocido por ambos.

Para la programación de pares, es bueno que las dos partes que se encuentran frente a la pantalla tengan las mismas habilidades al usar el teclado. También es bueno saber que, si su proyecto tiene necesidades de configuración especiales en el IDE, se configura de la misma manera para todos. Obtener un nuevo desarrollador es más fácil cuando las herramientas son las mismas para todos.

Pero si comparas eso con solo intentar ser más efectivo, entonces realmente no vale la pena

Sí, es un poco de una señal de alerta que la administración considera a sí misma como un mejor juez de las herramientas con las que sería más eficiente que usted.

No es una bandera roja en sí misma.

A veces, la gerencia debe tomar decisiones . Cualquier problema que requiera estandarización en algo tiende a caer en esa categoría. Una vez trabajé en un cliente que había permitido que los estándares se desviaran durante algunos años y tenían más de 20 herramientas diferentes de SCM. Lo que comenzó como una elección independiente por parte de diferentes equipos de desarrollo se convirtió en una pesadilla logística que obstaculizó gravemente el intercambio de habilidades y la colaboración en el código en toda la organización. La compilación integrada fue ..... er ..... no muy integrada .....

Además, no es práctico ni necesario consultar a todos para cada decisión . La medida en que esto debe hacerse depende de la cultura de la organización y la importancia / complejidad de la decisión. Por lo general, tomaría una de estas opciones menos pesadas de consulta:

1. Tome la decisión usted mismo, si tiene suficiente conocimiento de los pros / contras y no es una decisión lo suficientemente importante como para requerir una consulta amplia.
2. Consulte con algunas personas clave (quienes probablemente serían los desarrolladores senior más calificados para tomar la decisión).
3. Aumente el hecho de que está tomando una decisión para todos los afectados (correo electrónico, reunión pública, reuniones de equipo). Diga cuál cree que es la decisión correcta, pero que está dispuesto a cambiar esto si surgen nuevas pruebas de lo contrario. Invite a las personas a presentarse individualmente si tienen algunas opiniones importantes
4. Invite a las personas a formar un sub-equipo para revisar las opciones y recomendar una decisión. Una buena opción si realmente es una decisión cercana, usted no sabe la respuesta y desea que los involucrados participen en la decisión.

Para algo como herramientas de desarrollador (que es un tema potencialmente polémico) probablemente haría 2 seguidas de 3 o 4. es decir, definitivamente habría algunas personas con las que no hablaría personalmente sobre el tema, pero en el Por otro lado, la mayoría de las personas clave tendrían la oportunidad de contribuir a la toma de decisiones.

Para mí, la bandera roja real estaría presente si cree firmemente que se ha tomado una decisión incorrecta (mal == perjudica a la empresa en lugar de no elegir su herramienta favorita). ¿Cómo reacciona la administración cuando se plantea este problema?

• La buena administración escuchará su argumento, le agradecemos sinceramente por los comentarios y reconsidera su posición en caso de que haya presentado nuevas ideas . Es posible que aún no estén de acuerdo con usted y que se apeguen a su decisión, pero apreciarán que lo haya planteado con ellos y le brindarán la cortesía de decir por qué se apegan a su decisión. Incluso podrían cambiar la forma en que toman tales decisiones en el futuro, y si usted obtuvo buenos puntos podría incluirlo en su lista de "personas inteligentes para preguntar".
• La mala administración se pondrá a la defensiva, diga que "se toma la decisión" y otras tácticas similares para evitar enfrentar el hecho de que pueden haber tomado una decisión equivocada. Pueden verte como un "alborotador". La empresa sufre, al igual que su fe en la gestión. Esta es una bandera roja real! ¡Salga mientras puedas!

Si está utilizando maven o algo similar, no debería importar qué IDE esté utilizando. Puede haber casos en los que uno esté vinculado a un IDE específico como eclipse, si hay complementos en los que confía.

Creo que debería poder elegir su propio IDE, el IDE en el que es más productivo. Sin embargo, como ya dije, hay casos en los que tiene sentido usar un IDE estándar.

Tendría instalado el IDE "mandatado por la empresa", pero seguiría haciendo la mayor parte de mi trabajo en cualquier IDE que quisiera, no es como si alguien pudiera decir qué IDE se usó para editar un archivo de origen.

En el frente de IDE vs. editor ... para casi todos los idiomas, fuertemente prefiero un IDE (IntelliJ) porque hay mucho más que puede hacer por usted que un editor. Hay algunas cosas por las que vuelvo a ST2 o Emacs, pero para la codificación del día a día, a pesar de lo mucho que me gustan ambos ST2 / Emacs, el IDE casi siempre gana.

Todos los equipos en los que he estado han tenido una gran cantidad de IDE y editores: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine: nunca ha sido un problema. Nunca.

Para mí, esto habla de un malentendido en los altos niveles de la organización, en cuanto a lo que realmente importa. Lo que importa es dejar que los buenos programadores hagan lo que necesitan y utilicen las herramientas que los hacen más cómodos. La uniformidad de IDE tiene muy poco que ver con la comunicación real que tiene lugar sobre las cuestiones esenciales de la arquitectura de objetos, pruebas de unidad, algoritmos, etc.

Tener el mismo IDE que el siguiente tipo solo significa que ambos sabemos cómo navegar por el código con los mismos accesos directos, y cómo se configura nuestra compilación / configuración. Nada de lo cual importará cuando se habla de problemas de código real.

Mira, es habitable, dependiendo de otros factores de la empresa. Siempre puedes usar tu propio editor preferido para las cosas del día a día. Y tal vez su grupo está haciendo otras grandes cosas que crean una gran cultura. Pero los IDE obligatorios son un gran paso en falso de la OMI. Para mí, si yo estuviese entrevistando con una compañía y me informaran qué IDE estaba permitido que pudiera usar, les agradecería cortésmente su tiempo.

En nuestra tienda Ruby hay una fuerte recomendación de usar el IDE que la mayoría del equipo disfruta (RubyMine), porque sabemos que hace el trabajo. y podemos enseñarnos mutuamente atajos, etc.

Los desarrolladores tienen la libertad de usar un IDE diferente, pero requerimos que tengan habilidades sólidas en ese editor si así lo desean. Si vemos a alguien luchando para navegar por su proyecto o editar texto en su FooEdit personalizado, RubyMine es para ellos.

Si un programador es un experto en un IDE determinado, deberían usarlo. Si no son expertos en ningún IDE, probablemente hay uno o dos que son muy comunes para su lenguaje de programación, o dentro de su equipo, y probablemente tenga sentido para ellos aprenderlo.

Ser forzado a estandarizarse en un IDE parece una idea terrible.

Deben examinarse los motivos por los que una empresa obliga a un editor o software en particular a sus desarrolladores. La parte paranoica (quizás no sea la palabra que estoy buscando) cree que podría haber algún tipo de seguimiento de productividad agregado al eclipse que están pidiendo a los desarrolladores que instalen. Un pensamiento mucho menos paranoico (de nuevo) sería que han pasado tiempo agregando herramientas de creación de productos a este IDE que facilitarían las cosas si todos presionaran el mismo botón para probar y construir su rama de código.

De todos modos, lo que trato de decir es que probablemente sea más que una simple burocracia, o un método para meterse con los jefes de los desarrolladores.

Esta es una bandera roja masiva. Todas las compañías tienen algunas ideas estúpidas, pero si siguen llegando otras señales de alerta, simplemente váyanse.

Es fácil perderse la motivación detrás de algunas decisiones, especialmente con un equipo en rápido crecimiento. La motivación para mudarse a Eclipse podría ser el hecho de que la mayoría de los desarrolladores parecen estar perdiendo mucho tiempo simplemente configurando el IDE y que solo existe una experiencia limitada en su empresa.

Simplemente tomaría la orden de moverme a Eclipse para indicar que debería tener la configuración de Eclipse en caso de que sea necesario, pero continúe su trabajo en su editor favorito. (Es posible que deba pasar a Eclipse gradualmente si su empresa comienza a implementar herramientas geniales dentro de Eclipse).

Bandera roja: esperaría si hubiera algunas órdenes irracionales más antes de preocuparme.

Una startup generalmente intenta mantenerse ágil el tiempo suficiente para descubrir un modelo de negocio sostenible. Una vez que se da cuenta de la parte del dinero, la administración se mueve para ampliar el negocio. En general, es cuando todos los primeros empleados de tecnología comienzan a irse, a medida que los procesos de ingeniería se endurecen.

Como usted sabe, no sabe qué hará realmente el código hasta que lo ejecute. Turing lo demostró en los primeros días de la computación. Esto significa que no existe ninguna medida significativa de productividad cuando se trata de escribir software. Sin embargo, para que la gerencia haga su trabajo, la productividad debe ser legible. Como no puede medir el código (y las personas lo han intentado, por ejemplo, líneas de código), medirán lo que pueden ver. Los programadores son más legibles que el software que desarrollan. El equipo de administración típico intenta controlar a los programadores para hacerles legibles estas cosas (en lugar de hacer su trabajo real: salir del camino). Y debido a que miden las cosas incorrectas, no funciona muy bien.

Habiendo dicho eso, todavía puedes recorrer un largo camino con un equipo débilmente acoplado. El equipo de desarrollo de Github tiene alrededor de 50 personas y rompen todas las reglas en los libros de texto de gestión empresarial. Ellos parecen estar haciendo todo bien. Los errores se arreglan (eventualmente). Las características se añaden. Los incendios se apagan.

Lo que es una gran bandera roja es si están tratando de escalar las cosas sin haber descubierto cómo ganar dinero. En ese momento, debe preguntarse cuánto valen realmente sus opciones y subvenciones no adquiridas.

Seguramente esta es una mala idea. Es inevitable que el equipo sea menos productivo, ya que tienen que aprender a usar nuevas herramientas. E incluso entonces no serán tan efectivos como con las herramientas que ya grok .

Desde que probé varias herramientas, siempre tuve la sensación de "gosh, este editor me está molestando con < insertar algún error / diferencia de la herramienta preferida >". Así que también será un inconveniente moral.

Pero, por supuesto, también hay ventajas para que todo un equipo use las mismas herramientas. Compartiendo configuraciones, skripts, plugins y todo ese tipo de cosas. Lo que no sería posible con una diversidad de conjuntos de herramientas.

Por otro lado ... ese último bit no sería necesario si todos usaran su software preferido. ;)

Puedes "usar" Eclipse mientras sigues escribiendo SublimeText2.

Esto significa tener Eclipse instalado y configurado para sus proyectos y ponerse al día con él para que se sienta igualmente cómodo usándolo si, por ejemplo, programación de pares. A nadie le importará (o al menos debería) importar qué editor utilizaste para escribir un fragmento de código que hayas confirmado, siempre y cuando el mantenimiento de tu configuración paralela no tome una cantidad indebida de tiempo y no te separes de la red. entorno de desarrollo estándar.

Si estás usando Git y tu ramificación está inactiva, no deberías estar usando los editores de cada uno de todos modos. Puedes simplemente empujar una rama y hacer que otro desarrollador la tire para que funcione si realmente no puede entender tu conjunto de herramientas. Forzar a todos a usar el mismo editor suena como un pedido de un jefe de negocios que quiere lucir inteligente pero que realmente no entiende la forma en que operan ustedes.

Si piensa en esto desde el punto de vista de la administración, la razón por la que lo están haciendo es por cumplimiento legal. La compañía es responsable de garantizar que todas las herramientas utilizadas se utilicen legalmente y que no afecten al producto que se está desarrollando. (Algunos editores son gratuitos para uso personal, pero no gratuitos para cualquier otro propósito, etc.) Auditar todas las herramientas que todos los desarrolladores quieran usar puede ser costoso. He visto que en los proyectos donde los plazos son ajustados, la administración será cautelosa sobre qué herramientas / bibliotecas / etc se utilizan para minimizar los cambios posteriores en el proyecto que son dirigidos por la gente legal.

En los proyectos de mayor seguridad, también existe la preocupación de dónde almacenan los IDE los archivos temporales y qué información se almacena entre sesiones.

Todo depende de las razones por las que tienen que recomendar Eclipse. Si los desarrolladores tienen problemas para configurar sus entornos porque todos organizan las cosas de manera diferente, puede haber una razón para recomendar una camisa de fuerza. Sin embargo, si todos estaban contentos y productivos usando lo que querían, hay pocas razones para imponer un cambio en algo tan profundamente involucrado en el proceso creativo.

Eclipse es mucho más que un editor: puede seguir usando su editor favorito para editar su código y confiar en Eclipse para el control de la fuente, la depuración y cualquier otra cosa que el flujo de trabajo obligatorio de la empresa quiera.

Una última cosa: el proceso de cumplimiento en este nivel puede indicar que la compañía pretende expandir el equipo de desarrollo y desea tener un poco de estructura en su lugar para que los nuevos compañeros de equipo puedan volverse productivos más rápido. Si crees que Rails (o Django) es un marco "de opinión", te darás cuenta de que tener una estructura ayuda a entender las nuevas aplicaciones más fácilmente.

La bandera roja no es tanto que se imponga un solo IDE / editor a cada desarrollador, sino que esta decisión, y especialmente la decisión sobre qué IDE / editor se va a usar, no fue tomada por todos los desarrolladores, y Quizás ninguno de ellos!?!

Ciertamente, sería mejor para los desarrolladores llegar a un consenso, especialmente porque obviamente están mejor calificados para la decisión (al menos en qué editor / IDE). Puede haber una buena razón para ajustarse y esa decisión debería influir en la preferencia de la administración, pero qué editor / IDE debería haber sido la decisión de todos los desarrolladores.

Lograr que 12 desarrolladores emitan algunos votos sería fácil. ¡Ciertamente hubo tiempo suficiente para hacer eso! La conclusión hubiera sido dolorosa para algunos de todos modos y podría haber terminado siendo Eclipse al final, pero etiquetar el requisito como una "bandera roja" en ese caso sería mucho más discutible.