El ‘pool’ de programadores

real_programmers Oigo esta expresión una y otra vez. Y la verdad, no siempre puedo levantarme de la silla, mirar a quien la utiliza y decirle que parece mentira que alguien con su responsabilidad y a quien se suponen experiencia y conocimientos en la gestión de proyectos siga creyendo en esta falacia. Desgraciadamente casi siempre que oigo esta expresión sale de la boca de alguien ‘con responsabilidad’. No existen los pools de programadores, olvídense. Yo al menos aunque oigo la idea una y otra vez, no conozco a nadie que la haya implementado con éxito.

Voy a tratar de explicar aquí porque ‘el pool de programadores’ es una idea equivocada desde mi punto de vista. Así la próxima vez que oiga a alguien decir ‘contamos con un pool de programadores’ o ‘ lo que necesitamos es un pool de programadores’ o ‘quiero crear un pool de programadores’, en vez de que se me hinche la vena, allí, en directo, podré simplemente decir: “escribí no hace mucho sobre eso en mi blog, quizá te interesé leer lo que escribí”, que suena bastante más sosegado…

En informática estamos muy familiarizados con la idea de ‘ pool’. El patrón es simple, cuando necesitamos con frecuencia un recurso difícil de obtener lo mejor es tener un conjunto de esos recursos dispuestos a realizar su función en el momento en que se lo demandemos. ¿Por qué no trasladar esta idea que tan bien funciona para hilos, conexiones, sockets u objetos costosos de constrir a los programadores? Parece que esto es algo natural. Pero como muchos antipatrones, la idea aunque atractiva no funciona. Los motivos son, desde mi punto de vista, varios.

Los programadores no son reemplazables simplemente sin un coste, sin unos riesgos, sin que el proyecto se vea afectado. Los hilos o las conexiones que pedimos a un pool son todos idénticos, tienen las mismas características y capacidades y van a realizar siempre la misma tarea. Pero los programadores, como personas humanas que son, no son homogéneos, no tienen las mismas capacidades, ni van a realizar siempre las mismas tareas. Es más, no nos serviría de nada un pool de desarrolladores todos homogéneos, puesto que las tareas de desarrollo que debemos abordar son heterogéneas, para cada una de ella se necesitan diferentes capacidades, y a menudo se necesitan las capacidades de más de un desarrollador, la capacidades de un equipo.

Cuando asignamos tareas a un hipotético pool de programadores, en principio quien realizará la tarea es el programador que se encuentre disponible, lo que para nada significa el desarrollador más adecuado. La diferencia de desempeño entre el desarrollador adecuado y el desarrollador disponible son muy elevadas, tan elevadas que por si sola invalidan la idea del pool de programadores.

Habitualmente, la replica suele ser del estilo: “eh!!! Pero si el desarrollador solo tiene que ‘poner ladrillos’ nuestro analistas se lo darán’ mascado’. Y nos aseguramos de tener los mejores analistas y seleccionar los adecuados’. Cualquiera que haya trabajado con este modelo sabe que no hay nada más difícil que implementar un diseño de otro, sobre todo si eres un desarrollador novel, como suele ser el caso. Las trabas de comunicación y los miles de detalles que hay que especificar hacen que no sea rentable hacer un diseño tan detallado como para que solo haya que ‘poner ladrillos’. Que nadie entienda con esto que creo que no es necesario el análisis y el diseño o los analistas, pero su labor es otra, su labor es la de establecer patrones, marcar pautas claras, escribir código especialmente sensible, vigilar la calidad del código, según la metodología asignar tareas a otros desarrolladores etc… Pero creo que no es productivo que el analista solo diseñe. Hay tantas decisiones que tomar en cada línea código escrita…

Otro tema capital por el que el pool de programadores no es una buena idea es por que es una idea muy alejada del concepto de construir equipo. Cuando actuamos como gestores de proyectos una de nuestras labores principales es construir un equipo. El interés en construir un equipo es claro: decenas de estudios demuestran que la productividad de un equipo bien engrasado y establecido es hasta un orden de magnitud más alta que la suma de la productividad de sus miembros. Si alguien quiere ahondar en el tema, no hay mejor fuente que Peopleware.

En un pool, en el mejor de los casos, podemos esperar que la productividad sea igual a la suma de sus miembros. Pero este nivel de productividad nunca se va alcanzar, en un pool de programadores, los cambios entre tareas, los cambios de contexto, se van a comer una porción alta de la productividad esperable.

¿Qué pensáis vosotros sobre los pool de programadores? ¿Alguno de vosotros ‘vive’ dentro de uno? ¿Alguno de vosotros disfruta o sufre uno en sus proyectos?

16 comentarios sobre “El ‘pool’ de programadores”

  1. Sí, hubo una vez en que trabajé en un “pool” de programadores. No duró mucho.
    Lo malo es que ahora lo que se propugna en mi empresa es “cero” programadores. Los proyectos se pasan a una empresa exterior, que a su vez los subcontrata a otra de la India. Al final consiguen un 30% de ahorro en el coste y un tiempo de duración del proyecto que es el doble del anterior.
    Lo del trabajo en equipo funciona, pero creo que los que toman las decisiones no lo han experimentado nunca.

  2. Excelente post Rodrigo, como siempre.

    Luis Martinez Aniesa: El trabajo en equipo funciona cuando el equipo en realidad trabaja y se coordinan bien las ideas, algo que es casi imposible, ya que en los equipos de trabajo no todos tienen la misma capacidad y sobre todo algo importantisimo, “las ganas de que las cosas queden bien”

    Un Saludo.

  3. Mi opinión es que en la mayoría de las ocasiones se practica el CDD (Contability driven development). Su primer principio es “Aquello que no aparece en el balance contable, no existe”. En el balance contrable solo aparecen “analistas”, “analistas programadores”, “programadores”…. Pero poco más.

    Es un asunto que se da mucho en la consultoría. Se venden horas de desarrollo y para poder cubrir cada mes el máximo número de proyectos se mueve a la gente como de si un sudoku se tratara. Al final son proyectos incompletos sin los recursos necesarios y sin el conocimiento del proyecto necesario.

  4. Luis, el problema es que crear un equipo es dificil, pero no estropear uno es más dificil aun. Ha pocos jefes de proyecto capaces de crear un equipo, pero el número de los que son capaces de conservar y proteger un equipo creando un entorno en el que el equipo pueda crecer tiende a cero. Como bien dices pocos gestores saben lo que es trabajar en equipo, están más acostrumbados a competir de formas poco sanas.

    Clperez, tu sabes bien que cuando trabajabamos juntos durante un tiempo tubimos un equipo, pero tardaron poco en cargarselo poniendo al frente a un gestor máa que mediocre, que en lugar de ayudar al equipo lo desmotivaba. Me apunto lo de CDD, es muy bueno!!!

    Un saludo!!!

  5. Como bien dijiste, este es un antipatrón que yo conocia con el nombre de “Yet Anothoer Programmer” (http://c2.com/cgi/wiki?YetAnotherProgrammer). El tema es que como todo antipatrón produce el resultado inverso al que se busca originalmente. La motivacion principal es sencilla: gestionar a los técnicos como “recursos” intercambiables. La fuerza actuante es, para no llamarlo ignorancia, el pensamiento lineal. Este pensamiento lineal, sobre el que algún dia te comentaré desde mi blog, es una especie de meta antipatrón utilizado por los administradores que piensan en forma sencilla y aparentemente lógica con resultados que vos ya debes de imaginarte.
    Bueno, imposible estar en desacuerdo.
    Saludos.

  6. Absolutamente cierto. Hace tiempo conocí a alguien cuya idea de gestión de personal la describía más o menos así: “vamos a hacernos con una cartera de buenos programadores de los que podamos ir tirando cuando los necesitemos; les hacemos contratos cortos y los mandamos a casa cuando terminen el trabajo”.

    Indignación aparte, esta criatura simplemente demostraba su absoluta ignorancia de lo que es este mundo.

  7. Jejejeje, ya me he leído la entrada titán. :-)))

    Evidentemente estamos más que de acuerdo como bien sabes.

    Sabemos que los desarrolladores no somos/son llaves maestras capaces de abrir cualquier puerta en cualqueir momento o situación, y creer que estamos ahí para cualquier tipo de cometido, y menos para utilizarlos pegando giros de 360º según los caprichos de quien ordena y manda.

    Y es que todo esto que has comentado Rodrigo y los comentarios de todos los que han participado, tienen en mente en el fondo algo fundamental para el desarrollo del Software… ¡¡¡la Concentración!!!.

    No hay peor cosa en el mundo del Software que los parones, los cortes de ritmo y las distracciones.

    Si a eso le sumamos la tensión que produce el esperar en cualquier momento que te llame el jefe de turno por la mañana (o cuando sea vamos) y te diga… “¡deja todo lo que estás haciendo y mañana allí!”… eso genera un clima “chachi piruli jamón pelotilla” para trabajar a gusto, a tope y con un buen rendimiento…. vamos… resultado = motivación baja.

    Cada empresa hace lo que cree más conveniente, pero muchas veces no todo lo conveniente es lo más acertado.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *