Me gustó y voté por la respuesta de mcottle, pero quiero cubrir algunas otras dinámicas y argumentos que las otras respuestas aún no han mencionado.
Primero, implícito en la respuesta de mcottle está el hecho de que debajo de cierto nivel de habilidad, algunos problemas son simplemente imposibles. Desafortunadamente, la forma en que descubres esto es que tu equipo lo intenta y falla, lo cual es muycostoso. Después de fallar, hay dos lecciones posibles para aprender de esto. Una opción es aprender que necesita desarrolladores más competentes y, por lo tanto, contratarlos y completar el proyecto significativamente por encima del presupuesto y el cronograma, pero al menos está preparado en el futuro. La otra opción es que dicho proyecto es "demasiado difícil" para su equipo y tales cosas no deberían intentarse en el futuro, es decir, usted renuncia al proyecto y efectivamente cualquier otro similar. Por supuesto, rara vez se expresará como "somos demasiado tontos para hacer esto", sino que se racionalizará como "nuestros sistemas son muy complejos" o "tenemos mucho código heredado" o algunos otros. Este último punto de vista puede deformar significativamente la perspectiva de una empresa sobre lo que es posible y lo largo que debería ser el desarrollo costoso. "
Una pregunta es, ¿cuál es exactamente el plan de su empresa? De acuerdo, contratarán programadores baratos y junior. Pasan tres años, ¿y ahora qué? ¿Qué hacen con el desarrollador que ha estado con ellos durante esos tres años? ¿Simplemente nunca le dieron un aumento? Las opciones aquí son las siguientes:
- Dan aumentos competitivos para retener a los empleados, en cuyo caso ¿por qué tendrían problemas para pagar las tarifas de los desarrolladores senior ahora? Aunque volveré a esto.
- Tienen tasas estancadas, lo que significa que eventualmente van a "reducirse" a los empleados que carecen de impulso y / o habilidad.
- Eliminan más activamente a los empleados de más antigüedad.
Los dos segundos casos implican una gran rotación de empleados, lo que significa pérdida de conocimiento de la empresa y pagos continuos a los empleados. En el segundo caso, básicamente está seleccionando desarrolladores malos, por lo que los costos aumentarán en forma de horarios cada vez mayores. La forma en que esto se desarrollará es que todo va bien en el proyecto X hasta que de repente Jim se vaya, que fue uno de los mejores desarrolladores, porque no ha recibido un aumento en dos años, ahora el proyecto "comprensiblemente" tomará mucho más tiempo ya que debe contratar y capacitar a nuevos desarrolladores junior que (presumiblemente) no serán tan buenos como lo fue Jim. Así es como recalibras las expectativas.
Incluso en el caso de que se proporcionen aumentos competitivos, si todo lo que tiene son desarrolladores junior, ¿dónde y cómo se supone que deben aprender? Básicamente, espera que uno de ellos aprenda buenas prácticas por su cuenta a pesar de su entorno de trabajo, y eventualmente asesore a otros (en lugar de irse a pastos más verdes). Tendría mucho más sentido "preparar la bomba" con algunos buenos desarrolladores. Lo más probable es que desarrolles una cultura de Expertos Principiantes . El resultado es que terminarás pagando tarifas de desarrollador senior a personas que son solo un poco mejores que los desarrolladores junior y que son culturalmente tóxicos.
Una ventaja de, particularmente, los muy buenos desarrolladores, que me sorprende que nadie más haya mencionado es que pueden ser fácilmente un factor multiplicativo . Es muy posible que un desarrollador junior y un desarrollador senior tomen la misma cantidad de tiempo para hacer una tabla. Sin embargo, un buen desarrollador no hará eso. Harán un generador de tablas que reduce el tiempo para que todos hagan una tabla. Alternativamente / adicionalmente, elevarán el límite de lo que es posible para todos . Por ejemplo, los desarrolladores que implementaron el marco MapReduce de Google probablemente estaban extremadamente calificados, pero incluso si los usuariosde MapReduce son completamente incapaces de hacer una versión distribuida masivamente de su algoritmo por sí mismos, ahora pueden hacerlo fácilmente con MapReduce. A menudo, esta dinámica es menos evidente. Por ejemplo, un mejor control de origen, pruebas y prácticas de implementación mejoran a todos , pero puede ser más difícil de rastrear hasta una persona específica.
Para discutir el otro lado por un momento, tal vez los superiores tengan razón. Quizás no sean necesarios desarrolladores más experimentados. Sin embargo, si ese es el caso, parecería que el desarrollo no es una parte importante de la empresa. En ese caso, simplemente eliminaría a los desarrolladores por completo y usaría software comercial o contrataría contratistas a pedido. Puede valer la pena explorar por qué no solo usan contratistas en lugar de un equipo interno. Si va a tener una gran rotación de empleados de todos modos, entonces aumentar los contratistas no debería ser un problema.