Ingenieros, artesanos o la reserva moral de las organizaciones?

Leía en el blog de Juan Gabardini un artículo sobre la construcción de metáforas para explicarnos a nosotros mismos (y a los demás) como se entiende esto que hacemos (esto que hacemos es software, aclaro por si hubiera algún lector de este blog y encima despistado) y poder aprovechas las lecciones aprendidas de otras actividades que sean compatibles o transladables a nuestra actividad.

La pregunta que se hace allí es: los desarrolladores son (somos) artesanos, operarios o ingenieros?. O dicho de otra manera, la mejor manera de pensar el desarrollo de software es con desarrolladores que hacen lo que les dicen traduciendo ‘algo’ a código (operarios donde la productividad está ligada al tiempo empleado en la tarea), con desarrolladores concentrados en los detalles y en el pulido de su trabajo utilizando una experiencia poco formalizada o ingenieros, que usan tecnología y se nutren del conocimiento científico para construir algo que antes no existía con un montón de objetivos en mente (muchos de ellos contradictorios)?.

Yo encuentro importante la búsqueda de metáforas, pero no puedo evitar sentir cierta incomodidad cuando escucho cosas del estilo de “en nuestra actividad, a diferencia de la actividad de los ingenieros civiles, tenemos un entorno cambiante”, “nosotros lidiamos con el cambio constantemente, no como los médicos: a ellos no les sale un órgano nuevo cada año”. Las frases anteriores son ejemplos de dos extremos que encuentro cuando escucho las metáforas que comparan nuestra actividad con otras: la primera frase es razonable y la segunda profundamente estúpida e ignorante. Aún con las que considero buenos metáforas, no puedo evitar la incomodidad que me causa ver que quienes se ponen a desarrollar isomorfismos usualmente conocen uno solo de los conjuntos (no es el caso de Juan G. que es ingeniero de los de verdad, no informático).

Yo creo que la metáfora del operario se ha demostrado inútil: la productividad no está asociada a la cantidad de tiempo. Además (y esto puede que sea un problema mío) encuentro terriblemente difícil separar las actividades de diseño y programación. No digo que tenga que programar hasta el último detalle para diseñar, pero si no tengo feedback rápido de un diseño, no me sale bien (y no recuerdo conocer a alguien que sí le salga bien). Eso, emho, hace un poco complicado aplicar las ideas de ese simpático cuáquero en nuestra actividad.

Soy menos terminante en cuanto a la metáfora ingenieril: no diré que los ingenieros civiles no se enfrentan con una forma de construcción nueva cada año entre otras cosas porque trato de no confundir marketing con ciencia (o aunque sea tecnología), pero pienso en dos cosas muy particulares de nuestra actividad:

• Es muy difícil imaginarse el producto terminado
• Hay una percepción (creo yo que con bases en la realidad) de que el software es fácil de cambiar. Ante un error en un puente, se lo usa como está (o no se lo usa) en cambio el software siempre parece fácil de cambiar.
• La naturaleza maleable del asunto hace que quienes tengamos ese ‘problemita’ de no poder diseñar sin construir no seamos inútiles completos.

El modelo de ‘operarios’ de una ‘software factory’ aporta poco valor, en eso estamos de acuerdo. Ahora, que hay del modelo ingenieril?. Yo diría (lo sufrí en la facultad) que es alejado de la realidad, algo inútil y de un optimismo bastante nabo e irritante. Así las cosas, si bien nos vendrían bien las metáforas dudo en encontrar alguna. Que somos? Ingenieros, artesanos o la reserva moral de la organización? (supongo que si hay algún lector joven se perderá la última referencia). Que el enfoque de 'trabajadores del conocimiento'? Y si vemos a que nos parecemos después de pensar cuales debieran ser nuestros valores?


Nota de un par de días después: Debido a algún problemita que arrastro desde mi más tierna infancia que me impide manejar medianamente bien cualquier tecnología que tenga que ver con la presentación de contenidos, he cometido algún error que hizo que blogger (que tampoco es the ultimate editor, admitamoslo) se comiera los saltos de línea.

Probabilidades y otros temas ásperos

Yo no soy bueno para calcular probabilidades, lo que me atormentó en mis clases de Probabilidad y Estadística en la facultad. Y me atormentó porque yo era (soy) particularmente malo en un tema que me parecía importantísimo y muy interesante. El hecho de que no sea únicamente yo y que el problema de calcular probabilidades sea un problema arduo para todos los humanos aportaba y (aporta) poco consuelo.

Me enteraba el otro día, leyendo el maravilloso 'The Drunkard Walk: How Randomess Rules our Lives' de Leonard Mlodinow, que el desarrollo de la teoría de probabilidades es del siglo XVI, y que uno de los primeros trabajos se debió al italiano Gerolamo Cardano, quien usó sus desarrollos estadísticos para pagarse la carrera universitaria desplumando incautos con los dados. La ignorancia generalizada de sus contemporáneos en el cálculo de probabilidades, le permitieron a Cardano sacar una ventaja considerable.

Pero no es en el desarrollo de la teoría de probabilidades que querría detenerme hoy, sino en uno de los mejores ejemplos, en mi opinión, de las dificultades que enfrentamos al querer calcular las probabilidades: el problema de Monty Hall.

El problema de Monty Hall es el siguiente:

Supongamos que estemos en un programa de premios de televisión ( siempre es bueno situarse en entornos académicos a la hora de hacer experimentos mentales ) donde nos enfrentamos a tres puertas, de las cuales debemos elegir una sin saber que hay detrás de ninguna de ellas. Como dice Mlodivnow, supongamos que detrás de una de ella hay algo normalmente deseable (una cuopé Maserati, por ejemplo) y detrás de las otras dos objetos indeseables (las obras completas de Shakespeare en rumano).

Ahora, debemos elegir una puerta. Luego de nuestra elección, el conductor del show, que sabe la respuesta, abre una puerta distinta de la que elegimos para mostrar una de las dos colecciones de Shakespeare y nos pregunta si queremos cambiar de elección. La pregunta es, deberíamos? o sería lo mismo?.

Esta pregunta fue planteada en la columna Ask Marilyn, donde una tal Marilyn vos Savant responde las preguntas del público. Marilyn vos Savant, dicho sea de paso, tiene un IQ de 228 que, mida lo que mida el IQ, la hace la persona con el IQ más alto del mundo (me resulta curioso que Marilyn se llame Savant). Marilyn respondió que sí, que si cambiamos nuestras probabilidades de ganar son de 0,5 mientras que si mantenemos la apuesta origina son de 0,33. Esta respuesta abrió las puertas del infierno: unos cuantos lectores, muchos de ellos con PhDs en ciencias, la corrigieron en distintos tonos. El problema es que, según parece, Marilyn está en lo cierto.

Cuenta Mlodinow que Paul Erdös se negó aceptar que la respuesta correcta era que se debía cambiar de prueba hasta ver una simulación.

Bueno, en mi probablemente único punto de contacto con Erdös (no solo no soy ni remotamente inteligente, sino que tampoco soy ni remotamente valiente ni honesto como fue él), yo tampoco pude aceptar la solución hasta que vi una simulación. Así que hice una simulación (está aquí (*)) y vi que, efectivamente, Marilyn estaba en lo cierto. Solo después de ver el resultado pude entender por qué conviene cambiar.

La clave está en que no es un proceso aleatorio completamente, ya que el conductor del show conoce cual es la respuesta correcta, y nos indica, abriendo otra, cual puerta seguramente no tiene el premio. Recorramos las posibilidades:

• Posibilidad A: hemos elegido la primera vez la puerta con el Maserati. El conductor nos muestra cualquiera de las dos puertas con los libros, y nosotros elegimos la que él no nos ha mostrado. Nuestra elección resulta tener la colección de Shakespeare y perdimos la coupé deportiva. Claramente, esta es la posibilidad perdedora.
• Posibilidad B: hemos elegido una que tiene libros detrás. El conductor tiene que mostrarnos una de las dos puertas restantes y nos mostrará la que tiene los libros. Cambiamos nuestra elección y elegimos, por lo tanto, la puerta que tiene el auto. Esta posibilidad es la ganadora.

Ahora, no es difícil ver que la Posibilidad A tiene una probabilidad de 1/3 (la probabilidad de que acertemos de entrada la puerta con el auto), mientras la segunda tiene una probabilidad de 2/3 de ocurrencia (la probabilidad de que no acertemos el auto de entrada). Dado que cambiar de puerta elegida hace la posibilidad B ganadora, y que la posibilidad B es la más probable, conviene cambiar.

Yo no fui capaz de verlo hasta no hacer la simulación. Más aún, mientras hacía la simulación cometí un error y no tuve en cuenta en el programa que el conductor sabía en que puerta estaba el auto y que debía evitar abrir esa en respuesta a nuestra primera elección. Por lo tanto, en mi primer programa, el conductor abría cualquier puerta no elegida y si esta tenía el premio deseado, paraba el juego. En este caso, cambiar la elección no mejora las probabilidades. Este error me hizo entender la cuestión: la clave está en que el presentador conoce la respuesta y abriendo una puerta con libros nos da información más detallada de donde puede estar el auto.



(*) Se agradece la señalización de cualquier bug que pueda estar alterando el resultado. Si alguien tiene ganas de jugar al WTF con el código, adelante, pero debo prevenirlos que será aburrido porque no soy un programador particularmente bueno. Los fuentes fueron compilados con Java 1.6.
En la clase Main, en el método main() tienen la inicialización de la variable 'debug' que si la ponen en 'true' van a ver paso a paso lo que eligen jugador y conductor. Para ver los resultados mejor dejarla en false.
En el método main() se llama dos veces al método jugar(). Los parámetros son tres:
Cantidad de puertas
Repeticiones del experimento
Indicativo de si se debe cambiar (true: se cambia de elección, false: no se cambia)

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.