Una gallina y un cerdo están juntos cuando la gallina dice: "¡Abramos un restaurante!".
El cerdo lo pinesa un poco y pregunta: "¿Cómo llamaríamos al restaurante?".
La gallina sugiere: "Huevos con Jamón".
El cerdo responde: "Mejor no, gracias. Yo estaría comprometido pero tú solo involucrado".
Del libro Agile Software Development with Scrum, página 42. Del año 2001. Por Ken Schwaber y Mike Beedle.
Esta es una fábula extraña; y con la que cuesta identificarse (aunque asumo que todas las fábulas que hablan del comportamiento humano nos causan ese mismo efecto).
Pero, sin duda, refleja una situación común en el ámbito del desarrollo de software (que es donde realmente apareció la fábula). Y ocurre que en un proyecto no todo el mundo sufre las mismas presiones ni todas las presiones resultan en el mismo esfuerzo mental (más sobre esto debajo).
En cualquier escenario relacionado con la tecnología el cerdo representa a aquel que saber realmente cómo funciona el producto. Es al que se le llama cuando los procesos operacionales no han conseguido resolver alguna situación y se necesita que la tecnología funcione. Esta persona está comprometida: debe comprender y recordar el funcionamiento porque sus olvidos pueden resultar en fallos catastróficos o pérdidas irreversibles. Por ejemplo: si un servidor deja de funcionar porque se ha llenado su disco, este cerdo será el que sepa qué borrar para restaurar el servico, sin poner en peligro los datos o la propia plataforma. Esta intervención no es la que sigue un procedimiento preestablecido: eso sería parte de la operación normal que habría precedido a la intervención del cerdo. No. El cerdo no está siguiendo ningún procedimiento en esta fase, sino que debe apoyarse en su conocimiento del proyecto en juego.
¿Y los pollos? Los pollos son todos los demás.
Pueden hacer sugerencias como "borra ese directorio" o "modifica esta línea", pero siempre lo harán contando con que un cerdo validará esta sugerencia. Pueden estar involucrados en el proyecto, tomar decisiones sobre opciones que proponga el cerdo, incluso ser los responsables; pero no son autosuficientes: necesitan al cerdo.
Y si un pollo empieza a sacar adelante el proyecto por sí mismo... Entonces se convierte en un cerdo. Y con esa conversión viene la presión de ser la última línea de defensa frente alas meteduras de pata.
La cantidad de carga mental requerida para hacer funcionar una tecnología o proyecto no está directamente relacionada con la complejidad propia de la tecnología, sino con la evolución que haya tenido esa aplicación particular de la tecnología o proyecto.
Por ejemplo: un esquema de nombres puede considerar reglas y ubicaciones fijas en el nombre para elementos que ya no están en uso, pero que sí existieron en algún momento del proyecto. Así que, incluso cuando ya solo quedan un tipo de elementos, el esquema de nombres obliga a tenerlos en cuenta. En muchas ocasiones el proyecto evoluciona sin que se produzca una limpieza o reorganización que simplifique el esquema. Incluso puede ocurrir que esos otros elementos sigan existiendo, aunque su uso o relevancia frente a los elementos nuevos sea residual. Pero que ahí siguen y hay que mantenerlos.
La cantidad de memoria de trabajo necesaria para actuar de forma comprometida en un proyecto, como un cerdo, es muy alta. Muy alta en comparación con el conocimiento limitado que se le puede permitir a un pollo. El pollo siempre cuenta con el cerdo para validar sus contribuciones.
Por tanto una persona solo puede ser cerdo en un conjunto limitado de proyectos; en un conjunto mucho más reducido que si actuase como pollo. Porque siendo un pollo requiere muchísimo menos conocimiento ya que cuenta con la tutela del cerdo.
Que el demonio está en los detalles es un dicho que aplica a esta situación: el salto que supone comprender el proyecto en su totalidad, en saber hacer funcionar las cosas en cuestión de horas y no de días o semanas, es lo que marca la diferencia entre un cerdo y un pollo.
Muchos proyectos no se pueden permitir quedarse sin cerdos. ¿Cuáles sí? Aquellos en los que ocurre que a) la tecnología sea de dominio público y que b) la propia historia del proyecto sea irrelevante en la implementación realizada.