Demostrando lo evidente: somos más eficientes trabajando en serie.

Recientemente hablábamos del límite de nuestro sistema nervioso central con respecto a la información que es capaz de procesar en el post ¿Cómo somos de buenos haciendo varias tareas a la vez?

Dicho post venía motivado desde un punto de vista práctico por una reunión diaria (Daily Standup que se llaman en el mundo ágil) en la que trataba de reforzar en un equipo de trabajo la importancia de hacer respetar  los límites del trabajo en curso -WIP- de un tablero Kanban. Para ello realizamos un sencillo experimento [1] que permite visualizar nuestras ineficiencias haciendo varias tareas a la vez. Creo que puede aportar más un ejercicio práctico que la mejor de las teorías sobre el funcionamiento de nuestra mente (para los no expertos como yo, claro).

El ejercicio consiste en hacer varias tarjetas de papel y entregárselas a uno de los miembros del equipo, quien deberá escribir el nombre de al menos seis de sus compañeros (uno por tarjeta). Cada vez que se completa un nombre entrega la tarjeta "al cliente" quien, cronómetro en mano, apunta el instante exacto de dicha entrega.

La misma persona realizará dos rondas: una paralelo en la que únicamente puede escribir una letra en cada tarjeta pasando a la siguiente hasta completar todos los nombres y la ronda en serie en la que escribe cada nombre completo antes de pasar a la siguiente tarjeta.

Los resultados se pueden ver en la imagen superior. El procesamiento en paralelo (representado en rojo) requiere de 63 segundos en completarse, mientras que en serie se tarda algo menos de la mitad (29 segundos). Pero si la analizas la ventaja del procesamiento en serie es mucho mayor, puesto que "el cliente" obtiene la primera tarjeta (con el nombre de Mario) en 3 segundos, mientras que en el caso del procesamiento en paralelo la recepción de la primera tarjeta (valor para el cliente) requiere 32 segundos. Comparando los efectos de la multitarea en este sencillo ejercicio con nuestro trabajo habitual de desarrollo de software podemos obtener algunas conclusiones interesantes.

En el procesamiento en paralelo se pierde tiempo por una parte en el desplazamiento necesario de la mano al cambiar la escritura de una tarjeta a otra y en el esfuerzo mental necesario para obtener la letra que sigue en cada nombre. En serie al estar únicamente trabajando en un nombre no necesitamos pensar en el momento de escribir ni desplazar la mano de una tarjeta a otra.

¿Es más ineficiente si cabe en el desarrollo software que en el ejercicio propuesto?

Mi impresión es que sí, analicemos la situación. El cambiar a menudo de tareas para volver a retomarlas más tarde implica:

• Cerrar el proyecto: ¿Salvo cambios? ¿Los protejo bajo control de código fuente? Si lo hago, ¿romperé la build?... Si es así, puedo estar infringiendo una de las reglas del equipo sobre la integración continua..., pero tal vez me de tiempo a volver a esta tarea antes de irme a casa ¿y si no...?
• Abrir el nuevo proyecto, en el mejor de los casos sobre la misma plataforma de desarrollo.
• Preparar el entorno de desarrollo: acceso a datos y casos de pruebas para la depuración, perfiles, etc. 

Todo lo anterior puede llevar no menos de 2 minutos pero en situaciones desfavorables la pérdida de tiempo puede ser mucho mayor.

Por otra parte, está el esfuerzo mental necesario para cambiar de tarea. No es agotador, pero si realizas el ejercicio anteriormente descrito notarás que estás obligando a tu mente a esforzarse más de lo necesario. Si cambiamos el ejemplo por una método de código fuente, el esfuerzo mental para concentrarme en el problema se elevará en varios órdenes de magnitud... y la ineficiencia a su par.

Hace un tiempo, a través de @jgarzas llegué a un interesante estudio [2] que te aconsejo si quieres profundizar en estos temas. Analizan los resultados de más de 10.000 sesiones de grabación sobre 86 programadores y 414 encuestas. Además puedes encontrar referencias a otros estudios de trabajadores del conocimiento, no únicamente ingenieros del software.

Por tanto, parece una buena práctica (me temo que no muy usada) finalizar las tareas que comenzamos en lugar de saltar de unas a otras pensando que no afectará excesivamente el rendimiento general. Te animo a realizar el experimento con tu equipo, es ciertamente instructivo y puede ayudar a recordarnos cómo deberíamos intentar trabajar: limitando el trabajo en curso, una de las reglas del método Kanban sobre el que seguiremos profundizando en este blog.

Referencias

[1] Este ejemplo lo he visto publicado en diferentes blogs pero no sabría indicar la autoría original. Tal vez de Henrik Kniberg (he visto muchas referencias a su blog) pero no estoy seguro.

[2] Chris Parnin, Spencer Rugaber. Resumption strategies for interrupted programming tasks. Springer Science+Business Media, LLC. (2010).