Interrupciones y ruido en el desarrollo de software

Al hilo del resumen que encontré sobre Peopleware, y dándole vueltas a como mejorar mi flujo mental, me he puesto a pensar en que a lo largo de mi carrera, he tenido la interesante desgracia de encontrarme trabajando en diversos entornos ruidosos y con una gran cantidad de interrupciones. De todos ellos, creo que ha habido tres que han sido especialmente representativos en cuanto a lo que suponen para el desarrollo de software, tanto el ruido como las interrupciones.
De estos tres casos, una vez enfriados a base de tiempo para un análisis mínimamente objetivo, puedo decir que tenían, en mi opinión, las siguientes características:

1. El primer caso lo experimenté trabajando en un entorno con más ruido de conversaciones y teléfonos del deseable, pero relativamente amortiguado con algunos metros de distancia. Muy pocas interrupciones, y muy informales.
2. En segundo caso, el entorno era muy ruidoso, con montones de conversaciones al lado, y varias decenas de interrupciones diarias tanto in situ como de correo. Un caso bastante extremo, la verdad.
3. En el tercer caso, el entorno no era más ruidoso que cualquier otro en el que haya estado, pero había muchísimas interrupciones in situ. Telefónicas y de correo sin embargo, había muy rara vez.

En todas las ocasiones, tuve que realizar trabajo de análisis, diseño e implementación de las aplicaciones que tocaban en cada momento y en todos los casos hice un análisis de mi estancia, inmediatamente tras cambiar de empleo, como de costumbre, para tratar de aprender de errores propios y ajenos (una pseudo tarea de cierre y evaluación del proyecto que casi nadie lleva a cabo por lo que veo). Así que este artículo se centra exclusivamente en la relación entre ruido, interrupciones y desarrollo de aplicaciones.
Y una vez comentado el contexto creo que puedo pasar a exponer las siguientes opiniones que me he formado a base de estas y otras experiencias:

1. El trabajo de análisis y diseño admite mejor el ruido que la implementación. En mi caso puedo, por ejemplo, realizar documentación o establecer la arquitectura de una solución, con un nivel medio de ruido. Sin embargo para programar necesito muy poco ruido y/o cascos (como manera de aislarme), o la tarea se ve muy mermada en eficacia.

1. El análisis y diseño admiten interrupciones en ventanas de tiempo [x] relativamente pequeñas, quizá de media hora. Estas interrupciones merman estas tareas, pero no hasta un punto excesivo que eche por tierra horas de trabajo. En cambio la programación (la que se haga bien, no parchear algún desastre) muchas veces requiere de un par de horas como poco sin prestar atención a nada más o puedes irte directamente al bar y la productividad habrá sido similar pero con algo más de alegría.

Supongo que otras personas habrán tenido experiencias similares o diferentes, pero estas son las que tengo de primera mano, así que tengo pocas razones para discutirlas. Por otro lado, el por qué el ruido y las interrupciones afectan de determinada manera a mi trabajo, merecen al menos un intento de explicación. Y aquí es donde van mis dos céntimos.

Creo que la razón de esta diferencia entre las necesidades de concentración de una y otra tarea, se debe a que las tareas de análisis y diseño, son tareas de alto nivel, abstracciones (por definición incompletas), a menudo incorrectas y/o, ambiguas (un poco al hilo de las leaky abstractions de Joel Spolsky), tareas además más “naturales” en el sentido de que no requieren de un marcado ciclo de trabajo tan formal (ojo, no digo que no sea formal pero hay un trecho) y dependiente de la tecnología (IDE/compilador, base de datos, flujos de trabajo con sistemas de control de versiones…) como la implementación en código y bases de datos. Por tanto las tareas de diseño y análisis son más flexibles para con los ciclos de abandono y retomado propio de las interrupciones. Yo diría (en un sentido positivo aunque no lo parezca) que el análisis y el diseño de los sistemas informáticos, especialmente en cuanto a software, son tareas incompletas y erróneas por definición, y como otros trabajos de diseño, se sustentan muy bien sobre el papel.
Sin embargo, en la implementación, cuando el programador recoge las especificaciones y diseños del analista (uno mismo en caso de que el analista y el programador sean la misma persona), y se pone a codificar, se acaba encontrando con todas las omisiones, ambigüedades y errores que han pasado por el tamiz de los diferentes roles y hasta sus manos: desde el cliente, pasando por la toma de requisitos, análisis funcional y orgánico y cualquier otra fase que queramos meter en medio. Y es entonces cuando todo ese trabajo que no se ha realizado antes, todo lo que se ha olvidado, omitido conscientemente, tergiversado… cualquier decisión que no se ha tomado, se atasca en la implementación, que necesita convertir toda la documentación, en un producto funcional y mantenible en el tiempo, y debe hacerse sin errores, porque la implementación no perdona, y si no “cae” en el compilador, lo hará en tiempo de ejcución en el entorno de preproducción, o peor aún, en producción.

Parafraseando a Richard Feynman: "Para lograr un éxito tecnológico, la realidad debe estar por encima de las relaciones públicas, de los diseños, análisis y requisitos tomados, porque la problemática que resuelve el sistema, los usuarios que lo van a usar, el compilador, la base de datos y el entorno de producción no pueden ser engañados.".


La necesidad de hacer algo sólido, sin errores, ni omisiones, desde lo que es la documentación incompleta (como decíamos, por definición), obliga al desarrollador a mantener un modelo mental del sistema muy detallado, mucho más que en las etapas anteriores, y esto cuesta mucho más “cerebro” (atención, modelos mentales detallados, datos, simulaciones, peculiaridades del entorno…) que en el caso del análisis (que puede abstraerse del entorno como poco). Supongo que por eso cualquier cosa que robe “cerebro” o lo ralentice, como las interrupciones o el ruido, son tan perjudiciales en esta etapa de implementación. Y quizá por eso también los técnicos tienden (tendemos) a dejar de ver el bosque en muchas ocasiones, de tanto árbol que tiene, con las consiguientes quejas (con razón o sin ella) de usuarios y comerciales.

Y ojo, esto no es una crítica al indispensable trabajo de análisis y diseño (que me parece crítico para poder llevar a cabo el proyecto con éxito), ya que en mi caso hablo de mi propia experiencia en los diversos roles, sino una reflexión sobre la posible necesidad de mantener a los programadores en entornos más tranquilos y relajados que los de los analistas. Es una invitación a incentivar el uso de cascos (quizá proporcionándoles unos con reducción activa de ruido), quizá ropa cómoda, pero sobretodo a dejarlos en paz durante periodos largos del día, aislándolos de interrupciones y distracciones indeseadas. Y también es una invitación a establecer relaciones estrechas y de confianza (laboralmente al menos), entre los miembros de análisis y desarrollo, ya que su productividad como equipo debería mejorar con un lenguaje común, conocimiento de los talentos y limitaciones de cada uno, buenas costumbres y manías. Al fin y al cabo no son dos recursos intercambiables como les gusta pensar a demasiados responsables de proyectos y departamentos de RRHH, sino dos tipos de diseñadores creativos (o deberían serlo) que van a realizar una obra común de carácter muy técnico. Son dos creadores (ahora que está de moda la palabra con la Ley Sinde) que van a colaborar (en el sentido de Pixar), y es por ello que más vale que se entiendan bien y sepan donde ceder ambos el lápiz y el papel o la decisión para obtener algo coherente, porque de no ser así, el resultado puede ser catastrófico.

Vídeo relacionado: Jason Fried 2010 en TED o Youtube.

Foto de Wiki Commons.

NOTA: Este artículo empecé a escribirlo hace 10 meses, pero diversas circunstancias lo han mantenido en un cajón durante largo tiempo.