El 'pool' de programadores
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?