Friday, March 27, 2009

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.

Wednesday, March 4, 2009

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)