Aprendiendo algo nuevo

El pensamiento Lean aplicado a la construcción de software me parece, al menos en forma general, un gran hallazgo. El origen oriental del pensamiento Lean explica por qué éste está cruzado de conceptos orientales. Como el pensamiento lean es una gran idea, en lo que podríamos llamar la inducción apresurada por proximidad geográfica, mucha gente se apresura a abrazar con entusiasmo todos estos conceptos orientales.

Yo soy escéptico. En particular, me causa cierta desconfianza la idea de ShuHaRi. Rápidamente, esta es guía de adopción de los principios Lean a la que subyace una teoría del aprendizaje. Según sus proponentes, los pasos del aprendizaje son tres:

• En el primero, se aceptan las reglas tal cual han sido formuladas y se aplican sin modificarlas.
• En el segundo paso, se intenta romper las reglas, por medio de una reflexión crítica y la búsqueda de excepciones.
• En el tercer paso, una suerte de iluminación, ya no se piensa en términos de reglas.

Esta idea del ShuHaRi es esgrimida con frecuencia por los evangelizadores de algunas metodologías ágiles que, sostienen, uno debe, en una primera aproximación, tomar la metodología tal cual ha sido propuesta sin cambiarle una coma, para, luego, al ir ganando conocimiento y confianza, poder adaptarla a las propias necesidades.

Yo encuentro unos cuantos problemas con la idea del ShuHaRi. El primero es que no me gusta (sí, es una cuestión de gustos) que me digan "suspendé un rato el pensamiento crítico y aceptá sin cuestionamientos, necesitamos que pospongas un rato tus ganas de evaluar críticamente". Me resulta difícil de explicar por qué no me gusta, pero diría que me siento víctima de un asalto conservador: me piden tiempo a ver si, a fuerza de mostrarme solo un marco, me acostumbro a pensar que ese es el único marco posible.

Otro problema que no puedo dejar de ver es que presupone que la evolución de la idea (en este caso, la evolución de la metodología) ha alcanzado algo así como la perfección o un grado muy parecido: "no la cuestiones porque sirve en casi todo y vas a tardar en darte cuenta en que no sirve". Acepto que el conocimiento es indispensable para que la crítica constituya un aporte útil y no la expresión de un barrabrava, pero para la crítica muchas veces sirve el conocimiento del contexto o del dominio de la idea: me considero capaz de hacer una crítica demoledora de la astrología sin saber como hacen los astrólogos sus cartas natales.

El argumento de "no podés criticar las metodologías ágiles si no las seguiste al pie de la letra un tiempo" me recuerda a los astrólogos. Y no me predispone de muy buena manera, la verdad.

También pienso que la idea es una sobresimplificación: la pregunta sobre como aprendemos dista de ser una cuestión cerrada y todo apunta a que es bastante más complejo que lo que el ShuHaRi propone.

Lo que sabemos hoy del proceso de aprendizaje tampoco es demasiado. Este hecho me hace escéptico ante los métodos de enseñanza que sostienen estar basados en evidencia científica dura o que tienen pretensión de infalibilidad o superioridad frente al resto. Dentro de ese grupo no puedo dejar de ubicar a el ShuHaRi.

Sabemos, sí, que el proceso de aprendizaje no depende únicamente de la experiencia. La experiencia se elabora en procesos mentales que permiten desarrollar conexiones entre conceptos. Sabemos además que hay estilos de aprendizaje y que estos varían entre las personas.

Este trabajo desarrolla una escala para clasificar los estilos de aprendizaje en una única dimensión de intuición-análisis en los extremos. Hay unos cuantos problemas con esto (una única dimensión parece una sobre simplificación, se equipara el estilo analítico con el hemisferio derecho y el intuitivo con el izquierdo, o al revés, y aunque se aclara que eso es una "metáfora útil", se alimenta uno de los mitos más tontos que circulan por ahí), pero al menos apunta en una dirección clara: los estilos de aprendizaje varían. De acuerdo a Allinson y Hayes, el estilo de aprendizaje intuitivo se maneja mejor con enfoques globales y el analítico ve los detalles.

Por otra parte, parece ser que ciertas variaciones en el estilo de aprendizaje varían con cierta correlación con el background cultural. Incluso hasta los sesgos de percepción podrían variar con el background cultural ( cuidado! El estudio no dice nada sobre el orden causal )

El mundo está lleno de personas que sostienen que han sido capaces de entender como entendemos y que, al desenredar el problema, pueden darnos métodos infalibles para aprender, o,por lo menos, que si sus métodos no son infalibles, al menos son consistentemente mejores que el resto. Esta gente va desde Rousseau hasta los que me mandan spam ofreciéndome clases de inglés que 'neurologicamente' me enseñará a hablar en pocos meses por un proceso de programación neuro-lingüistica.

Yo esperaría más prudencia a la hora de adoptar teorías sobre el aprendizaje que lleven a desarrollar estrategias de enseñanza y adopción de conceptos y metodologías. Creo que la prudencia está justificada.

Por dónde comenzar

En un grupo dedicado a CMMI, un participante preguntó: "es el área de REQM (gestión de requerimientos) un buen lugar para comenzar con CMMI?". Yo no me atrevía a contestarle, en parte porque no quería exponerme a una quema por hereje.

CMMI plantea un área de proceso de gestión de requerimientos (REQM) en su nivel 2 con un solo objetivo específico: gestionar los requerimientos. Puedo imaginarme que significa 'Gestionar los Requerimientos', pero si uno anda corto de imaginación, el SEI proporciona una guía.

El SEI define como único componente obligatorio del modelo de CMMI a los objetivos específicos y generales, mientras que las prácticas son componentes esperados (o deseables?). Menos obligatoria es la, emho, siniestra lista de productos típicos (que es capaz de incluir un producto llamado ‘lista de criterios para distinguir las fuentes apropiadas de requerimientos’), así que nos quedamos solo con la descripción del objetivo.

La idea, según la definición de CMMI, es mantener un conjunto de requerimientos aprobados y consensuados a desarrollar. Ni más ni menos que un backlog.

Nada en la definición de CMMI dice que ese backlog no debe cambiar, ni que el nivel de consenso debe ser el mismo para todos los requerimientos del backlog. Es perfectamente posible que convivan en el backlog requerimientos de los que se tiene un entendimiento profundo con algunos que son comprendidos vagamente. Si esto no fuera aceptable para CMMI, daría lo mismo: sería inevitable. El problema viene cuando uno trabaja en un entorno donde no se acepta que los niveles de entendimiento diferentes generan grados de compromiso diferentes.

La gestión de requerimientos según CMMI implica mantener las relaciones entre los requerimientos y de estos con el plan de proyecto y los productos producidos. Esto es algo que uno puede hacer en la forma tradicional, armando planillas donde se relacione cada requerimiento con cada tarea identificada con cada producto de trabajo. Y cada producto podría ser un componente identificado en los modelos de diseño. Y lo mejor, hacer todo eso de entrada, antes de tirar una sola línea de código.

También se podría entender que el producto en un producto de software es el módulo a ser desplegado. Así, un determinado requerimiento está relacionado con un cierto build de una cantidad de módulos (si tenemos un proyecto grande), y la relación entre un requerimiento y el plan se completa indicando la fecha en que suponemos liberaremos el requerimiento, si es que la sabemos. Y por supuesto, no tenemos que entender como encajan todos los requerimientos antes de comenzar a desarrollar el primero, porque el entendimiento es un proceso iterativo.

Yo veo una pequeña diferencia entre las dos opciones, y es que la primera es irrealizable.

Además, CMMI también indica la necesidad de la gestión de cambios de requerimientos. Los agilistas acuerdan (acordamos) en que el control de cambios no debería servir para impedir el cambio, pero es útil conocer la tasa de cambio de un backlog porque es útil saber cuan bien venimos entendiendo el producto a construir.

Además, me gustaría agregar un detalle: recuerdo los valores ágiles de responsabilidad, honestidad, y demás virtudes. Pero ocurre que la gente es gente, y cuando las papas queman y alguien pregunta por determinados retrabajos o por qué se ha invertido seiscientas horas de desarrollo en algo que debería haber tardado doscientas, no es descabellado esperar que quien nos ha guiado a través de un camino sinuoso intente endilgarle la responsabilidad a otro. Quiero decir: que un Product Owner que nos ha hecho trabajar y retrabajar haciendo una cosa y luego la contraria continuamente intente explicar el poco valor conseguido luego de un tiempo considerable hablando de la falta de habilidades técnicas de los programadores.

Pienso que quizá no todos los requerimientos del backlog deban ser sometidos al control de cambios, solo aquellos donde se ha consensuado un cierto nivel de entendimiento, ya que muchos requerimientos del backlog ingresan a él simplemente como recordatorios de que algo hay que hacer respecto de un determinado tema. Pero aún así, el control de cambios es necesario.

Así planteadas las cosas, no se si el área de REQM es un buen lugar para comenzar por CMMI. Lo que me queda claro es que si no se ha comenzado a pensar como gestionar los requerimientos de un proyecto de software, no se está en condiciones de comenzar el proyecto. Dicho de otra manera, REQM no es un buen lugar para comenzar con CMMI, es un lugar por el que tenés que comenzar salvo que quieras llevar tu proyecto al desastre.

CMMI y la agilidad: el largo y sinuoso camino a la paz

Ya había escrito sobre el asunto, basado en lo que SEI había publicado alguna vez. Hace unos meses, el SEI publicó un artículo mucho más extenso sobre la relación de CMMI y Ágil, analizando la historia de CMMI y del enfoque ágil, los problemas de comunicación entre ambas comunidades, y de la posibilidad de coexistencia.

En el enfrentamiento (si es que se puede usar esta palabra) entre ambos paradigmas, es el SEI el que, desde hace un tiempo, se ha encaminado a mostrar que la confrontación es, no solo innecesaria, sino que perjudicial.

Por su parte, la comunidad ágil, en tanto comunidad, no tiene una voz unificada: las reacciones que he escuchado incluyen la declamación de victoria (el SEI se rinde ante la victoria de la agilidad y no quiere perder su base de cliente), la indiferencia, o el acuerdo con la visión del SEI. Yo tiendo a compartir esta última opinión.

En este artículo, que no es una excusa para no leer el documento original, recorro los puntos que me parecen más interesantes. El documento se defiende de las acusaciones que relacionan CMMI con cascada, diciendo algo que es cierto: CMMI es básicamente un conjunto de objetivos, y las prácticas no son más que puntos de partida que sirvan para guiar al que adopte CMMI en la forma de lograr esos objetivos.

CMMI no es un estándar, lo que hace que esas prácticas no sean obligatorias. CMMI está injustamente asociado con el desarrollo en cascada: las prácticas y los objetivos no son procesos, nada específica que se deban ejecutar en un determinado momento del proyecto. El documento desliza críticas a sus propios appraisals por no tener en cuenta que CMMI no establece requerimientos, sino un marco para organizar el análisis y las acciones de mejora, diciendo textualmente que:

"However, for people and organizations that do not have the skills or experience to understand, interpret, and implement the practices and goals to their specific contexts, the informative material takes on the mantle of requirements. This situation is also true for appraisal teams and lead appraisers. Thus, the over-emphasis on specific model examples, typical work products, and subpractices often results in prescriptive processes with little gain in quality or organizational performance. "

Salvando el hecho de que a pocos puede culpar el SEI más que sí mismo de este problema (tal vez debe revisar a quienes le da patente de appraiser) la frase me parece gran resumen: el problema es que se toma el marco de CMMI, pensado para guiar y ayudar a pensar, analizar y actuar como requerimientos que toman la fuerza de mandamientos.

Yo veo un problema adicional, e iría más lejos: veo valor en CMMI, pero no veo valor en la certificación de CMMI. El hecho de que el mismo SEI cuestione a sus appraisals en un documento público no mejora mi apreciación de la certificación precisamente. Pero el problema, emho, no es este (que es coyuntural) sino otro (más bien estructural): yo en mis procesos de desarrollo hago unas cuantas cosas, que tienen que ver con algunas áreas de proceso de CMMI (como por ejemplo Verificación, Validación y hasta Análisis y Resolución de Decisiones), pero no me detengo a dejar 'rastro' (documentos formales) de estas actividades porque decido que no aportan valor. Eso provoca que un SCAMPI juzgue que mi proyecto no cumple con los objetivos de esas áreas de proceso. Me encuentro con un problema: si bien el proceso aporta valor, para llegar a la certificación tengo que perder valor.

Definitivamente, y dejando de lado cuestiones comerciales, la certificación no agrega valor.

Otro aspecto interesante del documento es su análisis histórico. Se hace una recorrida por la historia del desarrollo de CMMI, partiendo de los problemas del DoD y su necesidad de resolverlos. Admite que la asociación Cascada/CMM está justificada, ya que CMM se focalizaba en una serie de procesos y actividades que intentan obtener la descripción acabada de lo que hay que hacer antes de comenzar. Es una pena que no pueda ver de primera mano esto, ya que nunca leí nada de CMM de primera mano del SEI y han retirado la especificación, dejando solo información para la actualización de una a otra.

Menciona, además, algunas características del entorno que vio nacer a CMM: se trataba de un entorno donde lo que se buscaba era cubrirse, no buscar la mejor solución. Esto estaba generado por la naturaleza de entidad estatal del DoD y su necesidad de registración y transparencia para cualquiera que preguntara que se estaba haciendo con el dinero público, la forma de contratar y la naturaleza de los problemas que resolvían: software relacionado al control de aviones, misiles, instrumental médico y cosas por el estilo. Este último punto (negar la agilidad para desarrollos donde esté en juego la vida humana) es discutible, y no lo tengo claro: aplicaría un método ágil para construir el software de control de un misil?.

Como dice el artículo, lo que puede aportarle CMMI a un enfoque ágil son métodos y prácticas para apoyar y guiar la adopción de metodologías ágiles en una organización: básicamente, foco en la definición e integración de los equipos y el proceso. No es que no se pueda guiar la adopción de un enfoque ágil en una organización grande y compleja sin CMMI, pero CMMI ayuda a que los esfuerzos de adopción y expansión del enfoque ágil no queden en el folclore oral de la organización.

Asimismo, se reconocen algunos puntos que ningún agilista está dispuesto a negar: en necesario acordar una visión global de la arquitectura, a veces es necesario escribir documentación y, en definitiva, sin algo parecido a un proceso nos vamos al demonio.

Es muy interesante la comparación que se hace entre el paradigma ágil y CMMI en una serie de puntos. En particular, me interesaron dos puntos:

• El primero, que tiene que ver con el foco en la organización: mientras CMMI se focaliza en la organización completa, el paradigma ágil se focaliza en cada proyecto y en el equipo. Creo que vale la pena recordar que la focalización en la organización puede llevarnos al peligro de querer optimizar el funcionamiento de la operación de la organización y no del proyecto, y esto es, definitivamente, un peligro. Trato de explicarme: puestos a mirar la organización como un todo, nos podríamos sentir tentados de reducir los tiempos muertos de un equipo de analistas, cuando en realidad, desde el punto de vista de un proyecto complejo y particularmente sensible, es conveniente asumir esos tiempos muertos. No veo mayor problema aquí siempre que se recuerde que, a veces es conveniente que el foco esté en el proyecto antes que en la organización.
• El segundo, es el que tiene que ver con la confianza: el paradigma ágil requiere la confianza casi como un prerrequisito. Yo veo esto como una debilidad, porque a veces, hay que hacer cosas aún cuando no hay confianza entre las partes. Vamos, en algún momento se empieza y uno no confía la primera vez.

Y por último, lo mejor: el SEI me da la razón a mí (ja) en que la evidencia de que la agilidad funciona es, hoy por hoy, puramente anecdótica. Esto no implica que la agilidad no funcione, sino que es necesario un esfuerzo de formalización de los resultados.

Setenta balcones y ninguna estadística

Estoy deprimido. Me siento triste, desengañado, defraudado. Supongo que es lo lógico cuando uno se creía un tipo lindo, alto, atlético y carilindo y se encuentra con la imagen que el espejo devuelve. Pero, ahora que lo pienso, lo que me ocurre es peor: siento la desdicha de haberme sentido parte de un grupo (profesional, en este caso) superior a otro y comprobar con amargura que no es así.

Siempre creí que las ciencias blandas deberían copiar varias cosas de las ciencias 'duras' (me cuesta decir ciencias blandas y ciencias duras y no decir ciencias y pseudociencias o protociencias) y eliminar sus fallas más notorias: proposiciones no verificables, especulaciones que confunden plausibilidad con certeza, palabrerío confuso y poco definido, mucha hermenéutica y poca experimentación y cosas así. Y por supuesto, siempre creí que mi actividad en la informática me ponía más cerca de las ciencias duras (o ciencias, a secas, aunque yo sea un tecnólogo y no un científico).

Sigo convencido de lo que digo en la primera frase del párrafo de arriba, pero dudo mucho de la segunda, esa que me pone a mí del lado de los buenos.

Pienso que hay mucho valor en las metodologías ágiles. Pero últimamente he notado que nuestras discusiones tienden a parecerse a las discusiones de los ... ejem... científicos sociales: mucha elucubración sobre los resultados de determinadas prácticas, alguna que otra anécdota, pero ni una sola estadística.

Vi las encuestas de Scott Ambler. No están del todo mal, pero tienen unos cuantos problemas metodológicos que no permitirían considerarlas estudios concluyentes: el primero es que se anuncian desde su columna dedicada al desarrollo ágil o en las listas de desarrollo ágil (lo que habla de un sesgo en la elección de quienes responden).

Eso, sumado a que no se le pide a la gente que definan 'éxito', que expliquen la forma de medir la productividad ni la calidad, sumado al sesgo en la elección de quienes responden, no veo como se pueda pensar que se ha evitado razonablemente el sesgo de confirmación.

De hecho, la pregunta "como afectó la adopción de metodologías ágiles a la productividad/calidad/costos" deja mucho lugar para una variante del sesgo de autoservicio (perdón, no se me ocurre una traducción mejor) : las metodologías ágiles siempre pueden llevarse el crédito por lo bueno y ser inocentes por lo malo que puede ser atribuido a problemas del entorno. O incluso, podría ocurrir lo contrario, si los sentimientos de quien responden son negativos hacia el enfoque ágil. Creo que una mejor redacción sería "como resultó la productividad, medida en (X), de los grupos que aplicaban enfoques ágiles frente a los que no los aplicaban?" donde, por supuesto, hay que encontrar alguna manera cuantitativa de medir la (X).

Y por último, deja a librado al sano arbitrio de quienes responden decidir si están siguiendo prácticas ágiles. Resumiendo, la encuesta puede dar ideas intuitivas de hacia donde vamos, pero dista de ser concluyente. Y no encontré otra cosa.

Aún así, yo encuentro que en mis evaluaciones en abstracto y en las anécdotas que puedo recoger, las metodologías ágiles son un buen enfoque allí donde se pueden aplicar. El problema es que, pese a todo, no hay evidencia concluyente. O al menos, no la conozco. Si alguien la conoce, me alegraría el día.

Veladas esperanzas singulares

Hace un tiempo, había escrito sobre la singularidad, ese teórico punto en el tiempo donde logremos una computadora capaz de obtener conciencia pegando un salto cualitativo respecto al progreso observado en las computadoras para permitir que estas asomen a ese raro fenómeno que llamamos conciencia.

Hoy leo en la Dr. Dobbs un artículo que tangencialmente toca el tema. El artículo es bastante menos especulativo que el que apareció en Spectrum, y habla de problemas actuales que se resuelven mejor pensando en un software capaz de aprender del entorno por medio de la incorporación conocimiento y no en software estructurado como una cantidad de reglas fijas que se aplican en cada situación para decidir la conducta a tomar.

Así, dice el autor, uno podría enseñar a un vehículo espacial no tripulado (el autor fue CTO y CIO de la NASA) a sentir 'temor' ante determinadas situaciones, de forma que este las evite evaluando la intensidad del 'temor'.

Suena lógico y las redes neuronales produjeron más de un éxito, no es mi deseo negarlo.

Sin embargo, me parece, este modelo de aprendizaje se enfrenta con algunas limitaciones serias. En primer lugar, es deudor de la teoría del asociacionismo , que pretende que el aprendizaje es, simplemente, la formación de asociaciones entre conceptos. En su forma más extrema, el conexionismo, sostiene que las redes asociativas, expuestas a entrenamiento, pueden explicar toda la cognición. La idea del conexionismo sostiene que no se necesita más que el modelo de conexiones que se influyen unas a otras para explicar nuestra inteligencia.

No es mi intención y está lejos de mis capacidades tomar partido en la disputa académica, solo digo que me siento persuadido por el argumento de que nuestros procesos mentales se basan en las combinaciones de partes significativas, y muchas de esas partes significativas y del proceso combinatorio, muy probablemente, haya sido moldeado por millones de años de evolución y esté presente en nuestro cerebro desde que nacemos. La idea, que ha venido a cuestionar el conexionismo, se llama sistematicidad (sistematicity)

Volviendo al ejemplo del vehículo espacial no tripulado y su temor a las situaciones peligrosas, a nosotros nadie nos ha enseñado a sentir temor, como sabe cualquiera que haya convivido con un niño de pocos meses y observe sus miedos a la oscuridad, a la soledad, a los ruidos estridentes. El argumento cobra más fuerza cuando hablamos de animales. El 'miedo' es un sentimiento favorecido por la evolución (los peligros del entorno se encargaron de quienes no habían desarrollado un cerebro equipado para sentir 'miedo') que no se aprende. El golpe a la teoría del asociacionismo es inevitable: el aprendizaje se da sobre la existencia de un sistema especializado, siendo el aprendizaje más el seteo de algunos parámetros ('algunos' puede significar un número terriblemente alto), que la formación de asociaciones.

Noam Chomsky (en su faceta de lingüista) ha propuesto que el lenguaje es una capacidad innata, que sigue una gramática universal que tenemos impresa en el cerebro y que el entorno 'solo' viene a llenar algunos parámetros para que adoptemos nuestra lengua madre. Algunos experimentos parecen darle la razón (aunque solo sea un forma preliminar), y su idea de la gramática universal se ha extendido, al menos con un nivel de éxito que amerita ser tomado en cuenta, a otros ámbitos, como por ejemplo, la moral. (la manera en que nuestras intuiciones morales innatas pueden complicarnos la adopción de determinadas formas de trabajo podría ser un buen tema para un próximo post)

En este contexto, no diría que el conexionismo está muerto, pero al menos debe abandonar sus ideas más extremas, como que se puede aprender sin reglas que especialicen los instrumentos para el aprendizaje. O dicho de forma más clara: un software que aprende, para ser lo suficientemente confiable como para guiar un vehículo no tripulado que puede terminar estrellándose en la ciudad de New York (o en cualquier otro lado) debería tener una cantidad de reglas que lo preparen para aprender aquello que queremos enseñarle. Verdad de perogrullo? No para mis profesores de inteligencia artificial en la facultad.

El autor de la nota no dice directamente que los 'dispositivos de aprendizaje' que propone sean de propósito general, pero se orienta en algunas afirmaciones, que, en mi opinión, van demasiado lejos: asegura que es el ambiente el que determina como funciona la memoria, lo que está lejos de estar demostrado. O cuando habla de plasticidad ("plasticity": the ability to form connections and reinforce connections based on previous training) olvida mencionar las limitaciones que tiene la plasticidad de nuestro cerebro.

Tal vez la afirmación más extrema del autor sea que the machine's performance is modeling that of the mammalian brain. Esto se pasa unos cuantos pueblos: a lo sumo lo que se está modelando es la parte que creemos entender del funcionamiento del cerebro de los mamíferos.

Todo esto, aunque sea para no creer a libro cerrado las promesas del marketing más o menos encubierto que el tipo hace de su compañía en ese artículo.

Oportunidades perdidas y mejoras inesperadas

Con frecuencia caigo presa de la sensación de oportunidad perdida. No es de extrañar, porque, en definitiva, haciendo retrospectiva y con el curso de los acontecimientos ya claros, la mejor estrategia siempre parecerá algo así como obvia. Y uno, que siempre cree que ha intuido correctamente el curso de los acontecimientos, se lamenta de no haber elegido la mejor estrategia.

La sensación de oportunidad perdida me asalta con frecuencia cuando me pongo a pensar en mi carrera universitaria. No es que no haya aprendido nada, pero no puedo evitar pensar que tanto tiempo y esfuerzo debieron haber dado más.

Esa sensación me asaltó de nuevo cuando por una de esas malsanas casualidades di, por segunda vez en mi vida, con un librito pobre que fue escrito con el objetivo de introducir la problemática de la ética profesional en el desarrollo de software (o al menos así me lo presentaron). El librito en cuestión cuenta la historia de un accidente provocado por un robot que, al mover equivocadamente su brazo mecánico, mató a su operador. Sí, lo tuve que leer para una materia de la que prefiero olvidarme dada por un profesor del que prefiero no recordar su nombre.

Es de lo peor que he leído (y eso que he leído cada porquería, solo por citar algunas). No le falta ninguno de los tópicos: el programador prima donna que porque es un desordenado toma apuntes a mano en un cuaderno (y no en un libro de actas de escribano o en unos bajorrelieves en la pared de la oficina, como parece ser la opción que le queda cómoda al autor, dado que la wiki en 1996 no era una opción), el físico que refunfuña y quiere enviar a la cárcel a un tipo porque confundió elementos de una fórmula (los ingenieros saben que los físicos son antisociales, refunfuñan, difícilmente se les entienda algo alguna vez y son intolerantes con todos los que no entienden su oscuridades). Por supuesto, como el físico es físico y es un cabrón (que es lo mismo) le explica al periodista el error de programación sin hacer el más mínimo esfuerzo por no usar palabras técnicas y hacer el asunto comprensible para alguien no técnico (de hecho, si el error que describe el personaje del físico en ese libro tiene sentido, yo no lo entiendo).

Por último, hace su entrada el gran profesor de ética que, a través de una maravillosa entrevista, nos viene a dar todas las respuestas. Este último personaje sería un sentido homenaje que el autor del libro se hace a sí mismo. El autor es un genio, y no lo creen pregúntenle a él.

Que llevó a mis profesores de entonces a maravillarse con ese libro cuando un análisis de un hecho real hubiese sido mucho más rico? No quiero ensañarme con ellos, pero , que tal el análisis del desastre del Challenger y del informe completo de la comisión Rogers, en particular del informe en minoría del que ya hablamos?. Recuerdo que leímos el libro con moderado interés, pero la sensación de que la historia era demasiado obvia y los 'plot devices' eran bastante gruesos, sumado al tamaño injustificado, hacían que la historia no terminara de despegar.

El análisis del desastre del Challenger, por otra parte, era un hecho real: aún si alguien tenía la sensación de que la historia era demasiado obvia y demasiado orientada para darle argumentos a una tesis final, la realidad era incontrovertible. Si hablamos de ética profesional, el informe en minoría era un excelente ejemplo de lo que realmente implica la ética profesional y la honestidad intelectual. No puedo evitar pensar que hubiese sido muy enriquecedor conocer en la universidad unos cuantos autores que hoy pienso imprescindibles.

Celebro, por eso, la idea de Juan Ramonet, quien fue mi profesor en las materias de investigación operativa, de agregar 'El placer de descubrir' (de Richard Feynman y que incluye el informe sobre el desastre del Challenger) a la lista de libros a leer durante la cursada de una de sus materias. Celebro, además, haber tenido un profesor como Juan (*): dado que los humanos tendemos a recordar lo bueno y olvidar lo malo, el haber tenido un profesor así hace que piense que mi carrera ha sido mejor de lo que en realidad fue.


(*) Cuando lo conocí, Juan repetía que "la mejor prueba de la decadencia de la universidad de buenos aires es que yo sea titular de cátedra, cuando estoy a lo sumo para jefe de trabajos prácticos. Y lo peor es que soy uno de los mejores profesores". Con la probable excepción de que no pienso que no esté calificado para estar donde está, estoy de acuerdo con la frase.

Tengos unas cuantas cosas para hacer...

... pero me voy a tomar un rato para escribir este artículo. Escribo este artículo y luego, lo juro, sigo con el Gantt que tengo que hacer (*).

El asunto es que estaba posponiendo algunas obligaciones y en la búsqueda de buenos motivos para seguir posponiendo, di con un interesante artículo de Scientific American Mind (online acá) hablando sobre la tendencia a procrastinar.

Uno, que no cree en coincidencias jungianas, tiende a interpretar estas ‘casualidades’ como demostraciones de que en realidad la cosa no es tan rara y poco común: al fin y al cabo, si algo me ocurre no es que haya una fuerza misteriosa que lo guía sino que había una probabilidad razonablemente alta de que suceda. Según el artículo, el 20% de la gente procrastina (discúlpeseme el verbo) razonablemente seguido, lo que justifica unas cuantas páginas en Internet al respecto y un artículo en el Scientific American Mind.

Hay un motivo para procrastinar: evolucionamos en un ambiente donde la vida era bastante más impredecible que ahora (en el próximo minuto, muchas cosas podían matarte), donde la vida era mucho más corta y donde no tenía demasiado sentido pensar en el largo plazo. En ese ambiente, desarrollamos la tendencia a infravalorar las recompensas y las pérdidas cuanto más lejos estén en el tiempo (y no solo por el concepto de interés monetario) a favor de la satisfacción inmediata.

Como muchas de las cosas que hoy nos causan problemas (el artículo cita unos estudios que hablan de los problemas financieros, laborales y de pareja que sufren los americanos por culpa de esto), la procrastinación tiene, y particularmente tuvo, efectos benéficos. Quiero decir que es fácil dejar atrás algo que nunca sirvió y que no sirve. El problema viene cuando cosas que sirven o sirvieron por mucho tiempo se vuelven perniciosas.

Queda claro por qué la procrastinación sirvió y como ha evolucionado, no solo en los humanos, sino en nuestros primos monos. Cuenta el artículo que se ha sometido a monos a un estudio (lástima que en la edición online no estén las citas), que muestra la tendencia a procrastinar de nuestros primos cuando la recompensa se percibe como lejana en el tiempo.

Ahora, yo creo, como uno de los comentaristas del artículo, que a veces es una buena estrategia posponer decisiones y tareas: en caso contrario gastaríamos energías en cosas que, en perspectiva, no resultan ser tan apremiantes. Esto lo sabe cualquiera que haya trabajado en una empresa con la tendencia a adoptar problemas de moda: problemas que todo el mundo tiene en la boca un tiempo, que se asumen como la prioridad máxima a ser resuelta, se hacen millones de presentaciones mostrando lo terrible que es ese problema y el infierno que espera si no se resuelve pronto y de poco se va apagando el entusiasmo y el apuro, sin que la situación subyacente haya cambiado en lo más mínimo. Claramente, gastar energías en problemas así, dejándose llevar por los impulsos de la manada, no es eficiente.

El problema es que hay que decidir que cosas merecen nuestra energía y cuales no, y en el proceso podemos sobre expandir la tendencia a aplazar acciones y decisiones más allá de lo recomendable. Pienso que hoy nos amenaza más la procrastinación que el impulso descontrolado a resolver cuestiones que no valen la pena o el pensamiento obsesivo en el largo plazo. Como tantas otras intuiciones que tenemos del mundo, fueron moldeadas por la evolución durante millones de años en un entorno muy diferente al que nos construimos estos últimos cientos de años.

Acá, hay una serie de tips o consejos rápidos para tratar de manejar la tendencia a la procrastinación:

• Simplemente empezá, porque el progreso en una tarea muchas veces motiva. Además, no te pierdas en dilaciones de planificación porque la experiencia indica que la mejor forma de obtener información sobre la tarea es comenzar a hacerla (alguien dijo metodologías ágiles?)

• Si tenés enfrente una cuchara con moco y la tenés que tomar, hacelo rápido. No le sumes al displacer de tragarla el displacer de pensar que lo vas a tener que hacer.

• No te engañes: no trabajás mejor bajo presión. No es cierto.

La procrastinación es, básicamente, una tendencia que tenemos impresa en nuestros genes: sobrevaloramos la ganancia en el corto plazo (el sentirnos bien por dejar de la lado la tarea desagradable) versus la pérdida en el largo plazo, que, como decíamos arriba, tendemos a infravalorar.

No se al resto, pero a mí me sirve la racionalización de conductas nocivas como forma de intentar controlarlas. Entender que sufro algunas tendencias no por imbécil, sino porque mi cerebro actúa de determinada forma, me sirve para intentar controlar esas tendencias: abandono la tarea de intentar no sentir lo que siento, que demanda mucha energía y tiene un resultado incierto, para intentar que lo que siento no me haga actuar de forma autodestructiva o perjudicial para mí mismo.


(*) Pocas tareas se me hacen más procrastinables que hacer Gantts. Le comentaba el otro día a L., me convertí a las metodologías ágiles cuando leí que Fowler decía que los Gantts no son la mejor herramienta para aplicar al desarrollo de software