Entidades invisibles

En su última columna en el Scientific American, Michael Shermer se pregunta (y luego responde) cual es el origen de la tendencia a creer que nuestra vida está controlada por agentes misteriosos, invisibles y poderosos. La respuesta es más o menos la misma que se da desde los tiempos de Daniel Kahneman y que ha merecido ríos de tinta de autores muy recomendables como el mismo Shermer, Daniel Dennett, a veces Dawkins, Thomas Kida y seguramente se me pasan algunos (la respuesta corta es que los errores de tipo I son evolutivamente menos peligrosos en el corto plazo que los errores de tipo II, en todo caso, siempre se puede leer el artículo de Shermer completo, que es muy recomendable y explora las causas que nos han llevado no solo a reconocer patrones donde no los hay, sino a pensar que hay intenciones detrás de esos patrones).

El artículo abre con una enumeración de los agentes invisibles más populares:

Se cree normalmente que almas, espíritus, fantasmas, dioses, demonios, ángeles, extraterrestres, diseñadores inteligentes, conspiradores gubernamentales y agentes invisibles de muchas otras naturalezas, poderosos y guiados por intenciones controlan nuestro entorno y nuestras vidas. Por qué?

Nota al margen para quienes no sigan el debate de la ciencia y el creacionismo en USA (y que se expande al resto del mundo). Copiando del diccionario escéptico, el diseño inteligente es una creencia anti-evolución que sostiene que las explicaciones naturales sobre el origen de ciertas entidades biológicas no son razonables y que el proceso de creación de estas solo puede ser explicado a través de la presencia de un diseñador inteligente (i.e dios)

Y me quedé pensando... no faltan los gerentes, los project managers y los ejecutivos en esa lista?. De los ejecutivos (y particularmente, ejecutivos de finanzas) ya se encargaron antes y mejor que yo muchos otros, así que me voy a detener en los gerentes operativos y de proyecto. Se podría decir que el primer motivo para no incluirlos en la lista es que éstos existen (bueno, los conspiradores gubernamentales también existen y cada tanto se anotan algún que otro éxito, pero ni tantos ni tan espectaculares como se les atribuyen).

Concedido, los gerentes existen, cierto. Pero mi impresión, basada en algo tan poco científico como mi experiencia personal, es que las personas en los grupos de trabajo tienden o bien a despreciar a sus gerentes de proyectos, o bien a sobreestimar el alcance de su capacidad para influir en los acontecimientos.

La primera alternativa (el desprecio a los gerentes) es fácil de explicar, incluso cuando no es justificada. Ahora, me intriga la segunda. Y me intriga más cuanto he sido su víctima, de un lado y del otro: a veces he supuesto que mi gerente o director era un mago que podía mágicamente arreglar cualquier problema con el que me enfrentaba, y otras me tocó ser considerado el Mesías (de más está decir que el tiempo se encargó de juntar evidencia para refutar ambas ilusiones, aunque, como sabemos, las ilusiones suelen ser resistentes a las evidencias). Hoy veo casi con cariño la ingenuidad que mostré al pensar que R. (mi director en esos momentos) podía resolver cualquier cosa y al sentirme halagado cuando se me consideró el Mesías.

Tengo una visión del gerente de proyecto (puesto que ocupo) más parecida a la de alguien que no controla nada, a lo sumo trata con buena fortuna de acomodar su proyecto a un entorno que cambia (más allá de su control), adaptándose a lo que pasa y, muy de vez en cuando, siendo capaz de saber qué va a pasar.

Existe la Economía Comportamental (espero que se perdone esta traducción tan chapucera de Behavioral Economics), que es, según dice la wikipedia, una rama de la economía que aplica el conocimiento científico sobre los factores cognitivos y emocionales para entender mejor las decisiones de consumidores, prestamistas, inversores y otros agentes económicos. Sería un ejercicio de optimismo esperar ver en los próximos años la Gestión de Proyectos Comportamental, que podría ser una serie de técnicas y herramientas para la gestión de proyectos que tengan en cuenta lo que sabemos del funcionamiento de nuestra mente?.

Y una última duda... si tal disciplina existiera... refutaría o apoyaría a las metodologías ágiles de desarrollo de software?. Yo creo que las apoyaría, pero en definitiva me gustaría ver 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.

Escuchábamos ayer

"If we have learned anything throughout this year we have learned that this financial crisis is unpredictable and difficult to counteract", dijo Paulson estos días (un diario argentino, conocido por su exquisita redacción, tituló "Paulson: lo que aprendí de crisis es que es impredecible")

"Hace un año pensábamos que teníamos precios de commodities altos por diez años más, incluso hubo casi una guerra civil para ver quien se quedaba con la renta extraordinaria y hoy aquí estamos, con precios bajos", dijo (esta la escuché de primera mano) Juan Gabardini ayer mismo en una presentación de SPIN, para introducir su charla sobre Scrum mencionando una característica importantísima de este framework para desarrollo: no intenta predecir el cambio, sino adaptarse a él.

(Nota al margen: sí, también estoy podrido de usar la palabra framework para todo, pero sería mucho más difícil escribir sin esos sustantivos que a fuerza de uso indiscriminado ya no significan nada pero nos permiten, a quienes no somos el genial Georgie, terminar una oración más o menos de acuerdo a las reglas del idioma)

En mi actividad, el desarrollo de software, conocí mucha gente que, como Paulson, insisten en que el problema no es con intentar predecir el futuro, sino con la situación particular que estamos tratando: oigan, el sistema funciona, que esta vez nos haya salido mal no dice nada del sistema, sino de nosotros. Que la tasa de fallos sea tan alta, es un detalle que conviene ignorar.

Me gusta de Scrum (y de XP, y del enfoque ágil en general) que acepta que el futuro no se puede predecir, que lo que deberíamos hacer es prepararnos para el cambio, no intentar anticiparlo. Para los programadores, que gustamos de programar de la forma más genérica posible para asegurar el uso de lo que estamos desarrollando en el futuro, es un gran golpe. Tan grande, de hecho, que uno de los mayores promotores de las metodologías ágiles que conozco defendía, al menos hasta hace un tiempo, el desarrollo de módulos independientes del motor de base de datos para asegurar la posible futura portabilidad entre bases de datos (estábamos hablando de un sistema enorme, hecho a medida para una gran empresa, que dificilmente pudiera ser migrado a otro motor de base de datos)

Puedo pensar en algunas limitaciones de Scrum (por ejemplo, cuando la necesidad de fijar variables financieras de antemano es superior a la necesidad de asegurar que todos los aspectos del producto generado sean útiles) y ciertamente me parece que temas como la practica de arquitecture envisioning y las iteraciones cero y menos uno son una buena extensión, ya que necesitamos estar de acuerdo en algunas cuestiones básicas de arquitectura antes de comenzar a desarrollar algo, particularmente cuando lo hacemos desde cero.

Tampoco soy un gran fan de la postura absolutista que suelen tener los iniciadores de algo que sostiene que si no se sigue al pie de la letra sus sabias enseñanzas, te apartás de la verdad y el camino y lo que ya no sos un verdadero feligrés. Puedo entender que no tiene sentido hablar de la adopción parcial de un estandar (cosa que el imperio del mal continuamente hace y hará, al menos, hasta que logre dominar por completo al comité de estándares ), pero no me cierra que Scrum (o cualquier otra cosa) haya alcanzado su forma perfecta, o al menos, su mejor forma posible. Se podría decir que comete el mismo error que Kuhn, que pretende que su paradigma de la inconmensurabilidad de los paradigmas no cae víctima de lo mismo que pregona, pero voy a resistir la tentación de hacer de epistemólogo en pantuflas por esta vez.

A pesar de lo anterior, me parece que el balance es positivo en favor de las metodologías ágiles: aceptamos que no sabemos exactamente qué necesitamos, aceptamos que no sabemos exactamente cuanto nos costará construirlo y no pretendemos sostener que sabemos. Ese es un gran paso.

De la presentación de Juan Gabardini, me quedó dando vuelta un frase: "el Scrum master es el responsable por el éxito del proyecto, sin embargo, no tiene poder de mando sobre el equipo". A mí este concepto me hace ruido: que la responsabilidad por el resultado debe ir acompañada por capacidad para decidir es un concepto arraigado en todos nosotros, no solo en lo que refiere a proyectos (por ejemplo, no condenamos a asesinos que no tuvieran, al momento de cometer su crimen, la capacidad para entender que estaban haciendo) y no estoy seguro de que sea un concepto que deba ser revisado.

La presentación siguiente fue la de Santiago Ceria, que comentó sobre sus particularizaciones a Scrum. En una charla muy interesante comentó la lista de sus pecados: suele hacer minutas de reunión y algunos documentos adicionales. Al fin y al cabo, Scrum no hace a los humanos diferentes a lo que son hoy y el donde dije digo digo diego no se va a ir con ninguna met... digo framework de trabajo: los humanos somos muy buenos para eludir responsabilidad (incluso sin mala intención) y no alcanza con proponernos cambiar para cambiar.

Me aventuro a conjeturar que, en la mayoría de los ámbitos, las prácticas de las metodologías no ágiles ( o menos ágiles ) que apuntan a dejar rastro de las decisiones de cada uno, no van a desaparecer.

No solo qué, sino también cómo

No soy un fan de la teoría del justo medio, esa teoría que dice que si una persona sostiene que dos más dos da cuatro y otra dice que dos más dos da cinco, entonces la respuesta correcta debería ser cuatro coma cinco.

Aún así, me gustan las columnas de Scott Ambler en la Dr. Dobbs y su continua prédica sobre el 'agil revisado', donde argumenta a favor de un proceso agil con algunas prácticas agregadas para disciplinar el proceso.

No estoy siempre de acuerdo con enfoque de 'agil disciplinado', pero me parece impecable el punto que hace sobre los requerimientos funcionales y los no funcionales. Recuerda Ambler que la comunidad ágil ha hecho un esfuerzo mucho mejor con los RF que los RNF: estos últimos siguen dependiendo, en gran medida, de que el programador sea lo suficientemente bueno y despierto como para tenerlos en cuentas y saber como tenerlos en cuenta y son dificilmente implementables con la misma estrategia que las historias del usuario.

El problema con los RNF es que, por lo general, no son autocontenidos, y la idea del backlog priorizado del que se seleccionan historias para implementar completas dentro de un sprint requiere un cierto grado de independencia entre éstas. Se dirá que los RF no son totalmente autocontenidos e independientes, pero podríamos decir, para ser más rigurosos, que el grado de dispersión (inventemos la definición: cuantos componentes involucra un requerimiento) de un RFN tiende a ser mayor que la de un RF. Los RFN tienen que ver con cuestiones de rendimiento, disponibilidad, usabilidad que involucran, normalmente, a la solución como un todo., mientras que los RF son más autocontenidos.

No me cuesta estar de acuerdo con que sabemos como manejar los RF mejor que los RNF, pero no diría que es un problema de la agilidad, a lo sumo es un problema que venía de antes y la agilidad no resuelve, como sí resuelve el problema que el enfoque tradicional tenía con los cambios en las definiciones. De hecho, me parece que la mejor solución para la implementación de los RNF vino con UP (un proceso con cierta agilidad), aunque ya la esbozaba aquel que vió en la oscuridad en su mítico libro sobre los sucesos primigeneos: la construcción de la linea base de arquitectura, el proceso de diseño de la arquitectura (alguna buena palabra para decir 'envisioning'? http://www.thefreedictionary.co /envision ) o se desee llamar a esa tarea.

Me gusta la visión de UP, que llama a esa tarea la construcción de la linea base, por sobre la idea de llamarla architecture envisioning. El concepto de linea base incluye una característica que, para mí, lo hace superior: la construcción de software además del modelado de la arquitectura, mientras que el architecture envisioning, si bien no niega la posibilidad de hacer de sotfware que en realidad ande, no la adopta como central. Pienso, como argumenté en artículos anteriores, que toda cuestión delicada que pueda ser sometida a una prueba empírica, debe pasar por ella: una linea base nos da una mejor idea de cuan buena en la arquitectura de las que nos pueden dar un par de modelos.

Los modelos tempranos (inevitables, por otra parte) son promesas, más útiles para hacer una primera revisión crítica de las ideas que para representar las ideas en su forma final. Deberíamos tratar de validar esas promesas antes de construir demasiado sobre ellas.

Por cierto, y como nota Ambler, el asunto no se acaba ahí. La línea base de arquitectura da un excelente marco para que los desarrolladores entiendan las restricciones y los requerimientos no funcionales, así como la estrategia de resolución que se les dará en la solución que está siendo implementada.

La educación de los desarrolladores debe ser también parte de la solución. No soy un fan de los cursos de siete horas al día donde comemos mediaslunas en los breaks, pero me gustan las soluciones de elearning y me gusta esa habilidad que he visto en algunos arquitectos, líderes o gerentes de proyectos de motivar a su equipo a aprender.

Y por último, Ambler propone algo que me gustaría tener: un equipo de test independiente que pruebe todas las releases. Cuando he trabajado con un equipo de test independiente, este ha sido más un equipo de certificación que de prueba de software. El concepto era que el software debía llegar al equipo de testing sin errores, para que ellos certificaran que así fuera. Siempre pensé que un equipo de testing independiente del equipo de desarrollo pero integrado al proyecto, con la misión de encontrar los bugs y no de certificar su inexistencia, podía llegar a aumentar la velocidad de liberación y la calidad. Hasta ahora, parece que me quedará con las ganas de probar empiricamente si tengo razón.

Como quiero yo, un desarrollador, que funcione el equipo de test?. Tal vez sea un buen tema para otro post.

Ilusiones y Certificaciones

Estos últimos años, la revolución cognitiva se ha estado extendiendo hacia los libros de divulgación. También es probable que uno, en sus esfuerzos infructuosos para dejar de ser la bestia inculta que es, haya dado por casualidad con los autores que se dedican a escribir sobre el asunto (Steven Pinker, Noam Chomsky, Thomas Kida, por ejemplo) para creer, como el estudio mismo de la cognición explica, que la fiesta comenzó cuando uno dio con ella (o dicho más generalmente, que uno entiende como la situación 'normal' a la que se conoció en el primer acercamiento).

Encuentro estos libros sumamente interesantes. Me interesa saber que parte de lo que somos está en nuestra naturaleza y que parte ha sido moldeada por el ambiente. Por otra parte, encuentro el estudio sobre la cognición (en particular el estudio de los sesgos cognitivos), además de muy interesante, importantísimo para mi trabajo diario: saber en que trampas suele caer nuestro proceso intelectual podría ser útil, si es que tuviéramos la esperanza de hacer algo para evitarlas.

Hace poco, vía Diego Navarro he conocido a Nassim Taleb. Taleb, un simpático (es un decir) ex agente de bolsa, anda por el mundo gritandole a quien quiera oirle que el rey no solo está desnudo, sino que además es gordo, feo y bastante tonto: nos recuerda que suponer que sabemos algo sobre el futuro comportamiento de sistemas que, por su propia naturaleza, son altamente volátiles es caer víctima de un sesgo cognitivo llamado ilusión de control. Esto es, creemos erróneamente que podemos prever, al menos con cierto grado de aproximación, qué va a suceder. Y lo peor es que sobre esas predicciones fallidas, falsamente rigurosas, decidimos nuestra conducta y tomamos riesgos.

Taleb compara el uso de estos modelos predictivos con la medicina del siglo XVIII: los médicos y los pacientes suponían que sus rudimentarios procedimientos eran, al menos, mejor que nada, cuando en realidad lo mejor que uno podía hacer era alejarse de los médicos y sus tratamientos nocivos ( la mala interpretación de esta situación dio nacimiento a una de las pseudociencias más exitosas: la homeopatía. Pero ese es otro tema).

En forma análoga a los médicos de antaño, nosotros pensamos que nuestra 'evaluación del riesgo' es mejor que nada. Nos dan escalofríos de placer cuando nuestra evaluación del riesgo es cuantitativa y cuando le asignamos probabilidades a los sucesos que identificamos. Que no haya la más mínima evidencia de que las probabilidades que estimamos tengan alguna relación con la realidad no nos impide disfrutar como enanos haciendo esto. Incluso más, tampoco nos importa que lo que termine por pasar no haya sido identificado siquiera con una probabilidad baja en nuestras predicciones.

Es divertido leer a Taleb (bueno, sería más divertido si uno viviera en Marte). Es divertido reírse de los financieros. Al fin y al cabo, nosotros somos informáticos, no tenemos esos modelos predictivos y ya mirábamos con sorna a los managers que hacían matrices de cuantificación de riesgos. Estamos a salvo de esta...

... No, yo no creo que estemos a salvo. Nosotros caemos en nuestras propias versiones de la ilusión de control. Creemos que podemos controlar los riesgos inherentes a la selección de proveedores o a la selección de personas. Y creemos que los podemos controlar por medio de una certificación de una entidad venerable, que nos garantiza que la-empresa-que-desarrolla-software cumple con el nivel cinco de CMMI. O que la-persona-que-lidera-proyectos es Scrum Master o PMP o ambas cosas, o alguna otra cosa. O que la-persona-que-gestiona-infraestructura tiene una certificación en ITIL.

Antes me preguntaba si saber de nuestros sesgos cognitivos nos abre la posibilidad de hacer algo. Creo que si no podemos hacer nada, al menos sí podemos no hacer algo: podemos dejar de experimentar la sensación de confianza tan hija de la ignorancia y tan buena para el desastre. Al fin y al cabo, como clientes, que un proveedor haya pasado un SCAMPI no baja nuestro riesgo, así como que el gerente sea PMP no implica que el riesgo del proyecto esté bajo control.

No niego la utilidad de los marcos teóricos que sistematizan (con suerte dispar, hay que admitirlo) el conocimiento adquirido por la industria y dan la oportunidad de encontrar los propios puntos débiles, como señala Martin Fowler. Me corto las venas antes de negar la importancia del conocimiento, el entrenamiento y la educación formal y no formal (aunque, como diría Stroustrop, no hay nada interesante que se pueda aprender en tres meses, y eso incluye a ser un buen gerente de proyecto). Creo que la educación formal y no formal en forma complementaria son imprescindibles para mejorar.

Pero tal vez, convenga separar nuestra valoración del conocimiento y el examen crítico de competencias de las certificaciones de entidades venerables. O, en todo caso, vayamos nosotros por el conocimiento y dejemos las certificaciones para los comerciales.

Engañemos a la realidad

Hace un tiempo, hablábamos de Richard Feynman. Feynman fue una persona notable, pero no haremos otra biografía suya aquí, la red está llena de ellas. Un comentario que dejé en un post de Dirección de Proyectos hablando de él fue seguido por una magnífica entrada en ese mismo blog sobre lo que un físico puede aportar a un gerente de proyectos, y eso me motivó a seguir hablando del tema.

Feynman participó en la comisión que investigó el desastre del Challenger, y luego de un informe impecable, concluyó con una frase que debería ser leída y releida por cualquier persona vinculada la gestión de proyectos: "para crear tecnología exitosa, la realidad debe prevalecer sobre las relaciones públicas, porque la naturaleza no puede ser engañada"

Esa frase, que deberíamos tener tatuada en el cerebro, es el corolario del informe que decíamos, donde profundiza sobre las causas últimas del desastre del Challenger. La historia se cuenta en una excelente entrada del blog Historias de la Ciencia. Para los que no tengan ganas de leer el post de Historias de la Ciencia, se puede ensayar una explicación rápida: el Challenger explotó porque las juntas toroidales (unos anillos que aislaban los segmentos de los cohetes aceleradores de combustible sólido) perdían su resistencia cuando antes del lanzamiento eran expuestas al frío (por ejemplo, al frío de una mañana de invierno), cosa que la NASA sabía (o al menos, tenía buenos motivos para intuir).

Para los que no tengan ganan de leer el post de Historias de la ciencia y piensen que con los dos renglones anteriores alcanza, vayan y lean el post de Historias de la ciencia: es uno de los mejores post de uno de los mejores blogs

Ahora bien, como bien nota Feynman, las juntas toroidales no aparecieron ahí por arte de magia. Tampoco es que hayan estado funcionando como violines bien afinados antes del desastre. Feynman dice que bajo este hecho (esto es, la erosión de las juntas), se escondían unas cuantas debilidades organizacionales (desidia, presión por mostrar resultados), que, en definitiva, crearon el medio ambiente donde el problema de las juntas toroidales pudo aparecer y desarrollarse hasta ser un gran desastre.

El informe en minoría de Feynman en la comisión Rogers me genera cierta sensación de familiaridad, no porque haya trabajado en la NASA o porque me haya explotado algún que otro transbordador espacial. Por supuesto que el recorrido que haremos aquí del informe es liviano y no es excusa para dejar de leerlo entero.

A continuación, las partes del informe que más me han chocado.

El informe cita a los oficiales de la NASA diciendo que, dado que el transbordador es un vehículo tripulado "la probabilidad del éxito de la misión está necesariamente cercana a 1". Esto se llama wishful thinking y nos genera cierta perplejidad que la NASA diga que algo es seguro porque dado que lleva humanos dentro, debería ser seguro. Luego de la sensación de repulsión que nos produce tal muestra de pensamiento irracional de nada menos que los oficiales de la NASA, pensemos las veces que hemos esperado que un software funcione solo porque si no funciona nos echan a todos.

Sigue mencionando Feynman que las juntas toroidales ya habían mostrado erosión en vuelos anteriores. Dado que la erosión solo había llegado a un tercio del radio de las juntas, se concluyó que se estaba operando con un coeficiente de seguridad de tres (la erosión tenía que triplicarse para que la junta cediera). Feynman dice que "el equipo no estaba funcionando como se esperaba, y existe por lo tanto el riesgo de que pueda operar con desviaciones aún más grandes y no completamente comprendidas. El hecho de que un peligro no haya llevado a una catástrofe anteriormente, no garantiza que no lo hará la próxima vez, salvo que éste sea completamente comprendido". Otra vez la NASA dando muestras de wishful thinking y desidia. De nuevo, al asombrarnos de la falta de rigor ajeno, no perdamos de vista que, al mirar comportamientos anómalos del software que desarrollamos, solemos tranquilizarnos pensando que igual son casos esporádicos o poco comunes, o que hay mucho margen para ese aumento de memoria tan raro.

Más allá de las juntas toroidales, el informe en minoría (el informe de Feynman fue en minoría: solo lo firmó él) se ocupa del diseño del motor principal del Challenger, aparentemente no involucrado en el desastre. La forma de diseñar motores de este tipo consiste en ir ensamblando los componentes en una estrategia bottom-up, de forma que cuando se detecta un problema en un componente a un determinado nivel de integración, se puede corregir antes de pasar al próximo nivel de integración. Si algún problema surge en algún momento, se puede aislar y corregir, porque el problema está en aquello que se ha incorporado en el presente paso. El diseño y desarrollo del motor principal del Challenger siguió un procedimiento top-down: el motor se diseñó y se lo ensambló todo junto con pocas pruebas unitarias, lo que dificultó el proceso de encontrar y corregir errores.

Adicionalmente, los procedimientos de certificación se volvieron dudosos: una turbina con una fisura luego de un determinado tiempo de prueba en el banco de pruebas representa una prueba no superada para la FAA. Bueno, para la NASA si las fisuras no habían llevado a una fractura, la prueba había sido exitosa. El que nunca haya participado en un proyecto donde no existían pruebas unitarias, donde los componentes no se podían probar en forma aislada y donde se había redefinido el concepto de 'prueba superada' que tire la primera piedra.

Y por último, el hardware y software de aviónica. El proceso de prueba y verificación del software era estricto y seguro (más allá de que algún iluminado quería recortarlo porque tanta seguridad no era necesaria: la prueba de que tanta seguridad puesta en el desarrollo del software no era necesaria era que el software nunca había generado ningún problema), pero había un problema: el proceso de cambio en el software era tan complicado, que nadie se animaba a reemplazar el hardware y éste, para 1986, ya era obsoleto. No se si alguien le suena esta situación. A mí sí.

No pretendo yo agotar las lecturas de un informe producido por muchos años de experiencia de alguien de la talla intelectual de Feynman. Sin embargo, su lectura nos ha servido para tratar de extender por la organización los siguientes conceptos:

• No pienses que las cosas van a salir bien porque no te merecés las consecuencias de que salgan mal.
• No decidas que cierta anomalía es perfectamente aceptable y que no vas a invertir esfuerzo en corregirla sin antes explicar y explicarte el mecanismo que lleva a la anomalía observable. Puede haber una bomba atómica bajo la alfombra.
  
• Diseñá de abajo hacia arriba, probando cada componente independientemente y preparate para el proceso de debug, que va a hacer inevitable.
  
• Diseñá para el cambio: la plataforma de hoy tendrá que ser reemplazada mañana.

Y se honesto, porque, al fin y al cabo, la naturaleza no puede ser engañada.