Cómo los gerentes eligen lenguajes de programación

23

No es un secreto para nadie que los gerentes puedan imponer el lenguaje de programación que se utilizará para un proyecto y, a menudo, lo harán.

Siendo yo mismo un programador, nunca he podido entender esto.

Pero ahora creo que sí: acabo de tener una revelación cuando Joel Spolsky dijo en el podcast que deberían usar QuickBooks porque "todos los contadores del mundo lo saben". Esto me pareció muy similar a "elegí Java porque todos los programadores del mundo lo saben".

Ahora que he visto el mismo problema desde otra perspectiva, no sé mucho sobre contabilidad, pero sí sé algo sobre programación, me pregunto cómo un programador puede ayudar a garantizar que se elija el lenguaje de programación adecuado para un proyecto. ?

Ingeniero mundial
fuente
¡Siempre recuerde que un gerente es alguien que cree que nueve mujeres pueden tener un bebé en un mes!
menosSeven

Respuestas:

29

El error que cometen muchos programadores es que discutirán el punto (o simplemente estarán de acuerdo o en desacuerdo con él) basándose únicamente en el mérito técnico. Con la administración, y el negocio en su conjunto, primero tiene que discutir el caso comercial y los méritos para el negocio y los méritos técnicos en segundo lugar.

Esto va más allá de la elección del lenguaje de programación e impregna prácticamente todas las decisiones técnicas.

Déjame darte un ejemplo: PC. Joel argumenta (correctamente) que los desarrolladores deberían tener máquinas de primer nivel porque el tiempo del desarrollador es costoso. En esto tiene toda la razón. ¿Pero cómo argumenta esto? Simple:

Ejemplo: hago una compilación del código aproximadamente 20 veces al día. Cada vez lleva 3 minutos. Si tuviera una PC rápida, podría construirla en 1,5 minutos. Entonces, por $ 1,000 adicionales cada dos años, puedo obtener media hora adicional al día, lo que para un programador que gana $ 100k (con costos adicionales de otro 50% al menos), eso equivale a aproximadamente $ 10,000 por año.

Pero argumentar en el otro extremo es que RR.HH. decide que una talla para todos se refiere a las políticas y las PC, por lo que un trabajador del centro de llamadas gana $ 25k y un programador que gana cuatro veces que por alguna razón debería tener la misma PC.

La plataforma tecnológica y los idiomas tendrán muchos factores que intervienen en la combinación de decisiones:

  • Relación estratégica con proveedores particulares. Si su empresa es un Gold Partner de Microsoft (o como se llame ahora), buena suerte con Java o Python;
  • El departamento de TI argumenta una configuración particular porque el dinero para las PC sale de su presupuesto;
  • TI decide que todos deberían ejecutar Windows 2000 porque no tienen personas que ejecuten Linux;
  • Qué otros sistemas ya tiene la compañía (por ejemplo, si usan Java para todo lo demás, tiene sentido usarlo para esto, aunque por sí solo no sea la mejor opción);
  • Aversión al riesgo a diferentes plataformas o idiomas simplemente por falta de experiencia;
  • Más interesado en discutir el riesgo con la alta gerencia que en hacer felices a los desarrolladores;
  • Algunos gerentes toman las decisiones que toman simplemente porque tienen las manos atadas;
  • Razones presupuestarias, aunque esto también puede funcionar a su favor, ya que mantiene costosos despilfarros fuera de su casa como PVCS, cualquier cosa producida por Rational, etc.
  • Aversión del departamento legal a las licencias de código abierto;
  • No involucrar al personal técnico en la planificación y la estimación del proyecto;
  • Familiaridad por parte del gerente con una plataforma en particular (las personas técnicas también son culpables de esto, pero en ambos casos no es necesariamente algo malo, con muchas herramientas que pueden hacer el trabajo mejor, demonios).
  • Experiencia del personal técnico. Si todos son de un fondo C #, ¿por qué usarían Java, Python o Ruby?
  • Muchas otras razones

Cualquiera sea el caso, debe comprender la razón (y le garantizo que habrá varias razones) y argumentar los méritos en esos términos. Algunos programadores son bastante ingenuos en este departamento y parecen pensar que tales decisiones se toman por ignorancia o incluso por venganza cuando casi siempre hay muchos factores en juego.


fuente
Muy buena y detallada respuesta!
1
"saltos caros de su casa como PVCS, cualquier cosa producida por Rational". Ja! Divertido porque es verdad;)
Rig
Mi empresa es socio Gold de Microsoft, pero usamos CUALQUIER COSA que razonablemente necesitemos. Debes presentar tu caso y luchar por él, pero todo es posible para las personas inteligentes
Budda
16

Por lo que parezco en mi empresa: cuando los gerentes eligen un lenguaje de programación, generalmente lo hacen de manera muy conservadora, teniendo en cuenta qué tipo de habilidades de programación están actualmente disponibles en el equipo (y si sería fácil contratar fácilmente otros adicionales) ), si se trata de un lenguaje bien establecido, tratar de elegir algo que se ajuste a la infraestructura actual y no causar grandes esfuerzos para que se ajuste a lo que ya existe. Cuando los programadores eligen un lenguaje de programación, las cosas suelen ser un poco diferentes: a menudo les gusta tener un nuevo desafío y les gustaría tener la última tendencia y elegir algo donde puedan aprender cosas nuevas.

Idealmente, todo se reduce a discutir los pros y los contras entre el gerente y el equipo de desarrollo y encontrar la solución que mejor se adapte al problema. Esto generalmente implica mucho hablar y convencer :-)


fuente
¿Por qué los votos negativos?
2
Voté en contra porque no respondiste mi pregunta. Acabas de decir un montón de generalidades. Excepto por la última oración, que puede verse como una respuesta. Pero es bastante inútil.
14

Respuesta tardía, pero como todavía no hay una respuesta aceptada, lo intentaré. Lo tomo como dos preguntas e intentaré responderlas por separado:

¿Cómo eligen los gerentes los lenguajes de programación?

Depende en gran medida del tamaño de la organización y la experiencia del gerente, pero generalmente implicará evaluar la situación actual y los escenarios y requisitos futuros. Esto generalmente se hace a través de PESTLE o análisis similar, y solo para dar algunas muestras en cada categoría:

  • Político
    • "Nadie fue despedido por comprar IBM" - opción segura.
    • El CEO escuchó que Java es genial, bombo publicitario.
    • El arquitecto jefe ama .NET - proyecto para mascotas.
    • El lenguaje es controlado por un competidor hostil: por qué Google no confía en C #.
  • Económico
    • Costos de licencia.
    • Costo de la capacitación de desarrolladores.
    • Código base de los costos de migración.
  • Social
    • Compromiso del equipo.
    • Disponibilidad de habilidades en la casa (necesidades de capacitación, continuidad).
    • Disponibilidad de habilidades en el mercado.
    • Amenaza al status quo existente dentro del equipo de desarrollo.
    • Disponibilidad de una comunidad de práctica suficientemente grande.
  • Tecnológico
    • Mejora de la productividad.
    • Mejora de calidad.
    • Capacidad de interoperar con la base de código existente.
    • Adherencia a las normas.
    • Madurez.
  • Legal
    • Términos de licencia.
    • Control de tecnología (¿Quién posee y controla la tecnología? ¿Cuál es la estrategia de licencia futura probable?)
    • Cumplimiento legal y regulatorio.
  • Ambiental
    • Infraestructura existente dentro de la empresa.
    • Habilidades existentes dentro de la empresa.
    • Integración con socios externos.
    • Nivel de soporte tecnológico por entorno más amplio.

Luego, un montón de idiomas que coinciden con los criterios pueden evaluarse más a fondo utilizando SWOT , análisis de costo- beneficio o similar.

Todo el proceso puede ser bastante complejo, pero como resultado final, la mayoría de las empresas o equipos de proyecto optarán por la opción más segura, dadas sus circunstancias actuales, que aún pueden ofrecer las capacidades que necesitan. Muy a menudo puede significar permanecer en la plataforma actual por más tiempo.

¿Cómo puede ayudar un programador a asegurarse de elegir el lenguaje de programación adecuado para un proyecto?

Como se ha demostrado, con suerte, un programador típico normalmente tendría solo 1/6 del aporte total en el proceso de toma de decisiones. Y, por regla general, ¡a él o ella le interesarían las capacidades lingüísticas solo!

Bueno, la mejor manera de influir en la decisión parece tener una imagen más amplia del proceso de selección, hacer aliados dentro y fuera del equipo, crear un buen resumen sobre el aspecto tecnológico de las cosas y tratar de no concentrarse solo en las capacidades del lenguaje.

Y, por supuesto, uno necesita ponerse en la posición cuando un Gerente de Proyecto o Desarrollo (o cualquier otra persona a cargo) ve los beneficios de pasar por todo el proceso de evaluación y está preparado para considerar los riesgos e incertidumbres de cambiar a otro idioma en primer lugar. Para que esto suceda, debe demostrarse que:

  1. La plataforma actual ya no es adecuada.
  2. Una nueva plataforma promete beneficios que superan con creces la molestia.

Sin embargo, si hubiera preguntado "¿Cuál es la mejor manera de poder usar en el trabajo el idioma que me gusta?", La respuesta probablemente habría sido "unirse a una empresa que ya usa el idioma o comenzar el suyo".

Vlad Gudim
fuente
5

El gerente A va a un retiro de verano donde se encuentra con el gerente B.

A: Entonces, ¿qué idioma usas en tu empresa? B: Oh, usamos CA Visual Objects, hace que los drones sean mucho más productivos que COBOL.

Y así es como se tomó la decisión. Fin de la historia real.

Spikolynn
fuente
¿Qué compañía es esa?
3

Cada plataforma tiene lados buenos y malos. .NET es genial y poderoso, pero prácticamente te quedaste con los servidores de Windows. Ruby es genial pero lento. Sería difícil encontrar desarrolladores para Haskell.

El punto es que el lenguaje no afecta qué tan rápido se realizará el proyecto y cuán hermoso será el código, sino también las cosas que los gerentes se preocupan. Entonces, si desea influir en ellos, ahora debería preferirlos y encontrar tantos lados buenos en su perspectiva como sea posible.


fuente
1
Planteas algunos puntos interesantes, pero te equivocas al encontrar desarrolladores de Haskell. La mayoría de las personas que se programa en Haskell no hacerlo, hacerlo, por lo que en un trabajo, pero ellos quieren (y que por lo general son bastante inteligentes)
1
Sé que son inteligentes :) Pero eso significa que no harán trabajo de soporte porque es aburrido o tendrías que pagarles mucho. Es como COBOL realmente, podrías encontrar a una persona que lo sabe, pero tendrías que pasar mucho tiempo buscando y pagar más de lo que pagarías por cualquier otro chico.
No, no lo haría, conozco a más de 300 desarrolladores de Haskell que trabajarían en los mismos trabajos que hacen ahora por una paga considerablemente menor de la que obtienen ahora solo por trabajar en Haskell.
Rayne
2

Al separar las preocupaciones. Las empresas deben estar a cargo de las decisiones comerciales y la tecnología a cargo de las decisiones tecnológicas. Me gusta el término "responsabilidad aceptada". Si voy a aceptar la responsabilidad, también exijo que tome las decisiones que conciernen a mi dominio del problema. Las empresas nos dan a mí y a mis colegas tecnológicos las demandas comerciales y nosotros respondemos con una o dos alternativas de cómo podemos aceptar la responsabilidad de cumplir. Nunca debería ser como "lo haremos en Python o C #". Más bien;

"Podemos aceptar dos responsabilidades diferentes aquí: si vamos por este camino, podemos cumplir esto rápidamente y cumplir con estas demandas comerciales realmente bien y esto es un poco más difícil. También podríamos hacerlo de esta manera y eso da triunfo a las demandas comerciales. La alternativa A requiere estos recursos y la alternativa B significa que también debemos hacer esto y esto ... "

Luego, el negocio elige, pero tenga en cuenta que el negocio elige en función del impacto en las cosas comerciales, no en las técnicas. Y no pueden elegir entre alternativas donde la tecnología no está lista para aceptar la responsabilidad de la parte tecnológica.


fuente
Muy interesante.
1

Conviértete en el gerente. (mueca)

En serio, solo necesita discutir el asunto con el tomador de decisiones en cuestión y presentar sus argumentos. Si eligen quedarse con una decisión realmente incorrecta, entonces su competencia general probablemente no sea tan buena y podría valer la pena buscar otra cosa que hacer.


fuente
O son sus propias habilidades de comunicación las que han fallado y debe buscar perfeccionarlas.
También está eso.
1

Creo que la diferencia entre lo que estás hablando y lo que Joel estaba hablando es que la programación es una competencia central, mientras que la contabilidad no lo es. El punto usando QuickBooks es, presumiblemente, porque estás no un contador y contadores puede ayudar con él. Sin embargo, si la programación es su competencia principal, y presumiblemente lo es si usted es un programador, entonces las reglas del juego son un poco diferentes.


fuente
2
La programación, en la mayoría de los casos, no es una competencia central para los gerentes.
Bueno, presumiblemente, es una competencia central de la empresa o departamento de una manera muy diferente de la discusión de Quickbooks.
No puedo seguir ¿Estás comparando manzanas con naranjas?
¿Por qué el voto negativo? Acabo de señalar su lógica defectuosa. En cuanto a las manzanas y las naranjas, creo que la olla se encuentra con la tetera. De lo que Joel estaba hablando wrt Quickbooks es muy diferente a los gerentes que simplemente eligen Java.
1

Depende mucho de la personalidad del gerente:

Hay aquellos que buscan palabras de moda. Averigüe qué palabras de moda les gustan y úsela cuando hable con él en conjunción con el idioma que desea usar.

Otros solo confiarán en cosas que ellos mismos conocen (como VB 6.0, por ejemplo). Haga que su idioma de elección sea fácil de entender para ellos ('usted sabe, es como en el viejo VB', incluso si está hablando de Haskell ...)

Pero en realidad, la mayoría de los gerentes no son tan estúpidos como nos gusta pensar a los geeks, y se puede razonar con ellos. Lo importante aquí es que comprenda su punto de vista: generalmente no les importan los detalles técnicos específicos, sino los resultados. Así que no les digas que .net o Java o Delphi o lo que sea que tenga esta excelente característica megacool. Dígales que (ingrese su idioma aquí) es una buena opción porque la característica A reduce los tiempos de desarrollo en un proyecto como este, o esa característica B genera menos errores y, por lo tanto, acorta el tiempo necesario para las pruebas. Solo asegúrate de que tu argumento sea sólido, no le mientas.

En otras palabras: trátalo como un ser inteligente (probablemente lo sea).

Treb
fuente
1

Piensa en el lenguaje que se te pide que uses muy, muy duro. Asegúrese de saber que no es un buen idioma para el trabajo, luego pregúntele al gerente si puede sugerirle otro idioma mejor para el trabajo. Proporcione cualquier información que pueda que demuestre que el idioma no sería bueno para el trabajo y vea lo que dice. No puede doler :)

Rayne
fuente
Punto interesante Pero siento que la carga de la prueba debería estar en la persona que impone el idioma, no al revés.
En un mundo de cuento de hadas tal vez.
Rayne
1

Elegir el lenguaje de programación es a menudo una decisión comercial. A los clientes / usuarios no les importa. Aquí hay una breve cita (de http://www.ericsink.com/bos/Geeks_Rule.html ):

Los lenguajes de programación se eligen principalmente por motivos comerciales. Paso la mayor parte del tiempo trabajando con idiomas que realmente no me gustan porque los idiomas con los que me gustaría trabajar conllevan desventajas comerciales que superan sus méritos técnicos. Esa es la naturaleza del juego. Puedo aceptar la situación (mi elección) o encontrar un nuevo empleador. Quejarse de cómo no puedo usar Java o Python o lo que sea que esté en el trabajo simplemente no es una opción.

Peter Štibraný
fuente
Estoy de acuerdo aquí Pero también creo que es importante tener en cuenta que, dados los dos roles, Business y Tech, Tech tendrá la aportación más importante sobre qué lenguaje / marco satisfará las demandas comerciales. Los trajes rara vez tienen el conocimiento tecnológico necesario.
1

En primer lugar, la programación es otra forma de arte. Una forma muy lógica de arte. Si su gerente está interesado en sus extraordinarios proyectos de software, que en cierta medida son obras maestras, entonces pídale a ese administrador entusiasta lo siguiente:

Cuánta energía y tiempo le costaría a Rembrandt extra no pintar con su pincel favorito, sino un pincel que, después de una cuidadosa consideración del equipo directivo, se le entrega, hace 400 años y antes de que sus trabajos se hicieran famosos. ¿Valdrá más o menos su pintura?

Del mismo modo, si le está diciendo a un programador qué lenguaje debe usarse, entonces sea coherente y también dígale a un pintor qué tamaños de pincel deben usarse. O, alternativamente, ¡solo deja esta opción a las personas que necesitan trabajar con ella todos los días y (como la mayoría de las obras maestras) por la noche!

Sam
fuente
Crear arte usando pasteles versus pinturas al óleo sería una mejor analogía. Sin embargo, los pros y los contras aún se encuentran en el lado comercial: aunque el artista puede preferir las pinturas al óleo, el proyecto puede requerir materiales baratos / puede requerir menos tiempo de preparación / puede requerir más longevidad para este cliente / etc. Dicho esto, el artista debería participar en esta elección, pero debe darse cuenta de que la carga de la persuasión y la prueba recae sobre sus hombros.
lunchmeat317
0

Estos son conceptos diferentes.

Cuando contabilizas, compartes tus resultados: para impuestos, leyes, inversores, etc. Necesitan una herramienta para ver el resultado de tu trabajo, y esta herramienta tiene que ser bien conocida.

Al programar, usa cualquier herramienta que desee, siempre que genere un .exearchivo que pueda ejecutar en Windows. Esto es exactamente lo mismo que un documento legible de Quick Books en caso de contabilidad.

Por lo tanto, si desarrolla una tostadora, puede conservar su documentación interna en chino, pero será mejor que proporcione un manual en inglés.

Hay una cosa más: si las reglas de su compañía asumen que el resultado de su código no es un producto en sí mismo, sino un código fuente para él, entonces seguramente pueden decidir cómo se verá (eligiendo el idioma que desean).

Lo que eligen depende de sus objetivos: si quieren programadores fácilmente reemplazables, eligen Java; si lo envían a otro departamento será el requisito de ese departamento, etc.

Quassnoi
fuente
Metafóricamente hablando, el equivalente de tostadora de lo que estoy hablando es la gestión que requiere que la documentación interna esté escrita en español porque hay más personas que hablan español en la Tierra.
Exactamente. Si los ensambladores de tostadoras de habla hispana están más disponibles en el mercado laboral, la documentación, por supuesto, debe estar en español.
0

En mi experiencia siempre ha dependido de:

  1. ¿Tenemos los recursos para usar el idioma?
  2. ¿Tenemos los recursos para mantener el idioma?
  3. Si no tenemos los recursos para usar y mantener el idioma, ¿qué tan difícil / costoso es obtener esos recursos?
  4. ¿Cuál es el "futuro" del lenguaje (¿Va a estar presente y en uso por un tiempo?)

A menos que el proyecto necesite algo que solo un lenguaje / plataforma / tecnología / marco específico proporciona, todo se reduce a lo que ya sabemos y usamos. La contratación de nuevas personas y la capacitación de programadores existentes es bastante costosa para la mayoría de las empresas. Al contratar, siempre consideramos el idioma y nos aseguramos de que los candidatos sepan qué idioma (s) probablemente usarán.

Esperemos que tenga un programador que también sea gerente y que pueda representar a los programadores en este tipo de decisiones. De lo contrario, es una situación peligrosa y debe hablar con su gerente si sabe que se está tomando esa decisión.


fuente