Saturday, September 26, 2009

El castigo justo

Via Andrés Diplotti me encontré con una campaña para que el gobierno británico pida disculpas por la condena sufrida por Alan Turing.

La historia de Alan Turing, el hombre que rompió el código nazi (*), el hombre que ayudó a sentar las bases de las reacciones retroalimentadas ( el libro de John Gribbin 'Así de Simple' es muy recomendable y que ganas me acaban de dar de escribir sobre la ley exponencial y su aplicación al análisis de performance del software) es interesante y triste.

Los comentarios se escriben en el manchester evening news como reacción a la noticia dan un poco de asco. Desde el energúmeno que dice que Turing no se jugaba la vida como lo hacían los soldados (mi antimilitarismo visceral me tienta a escribir que de energúmenos que intercambien balazos el mundo está lleno, mientras que de genios que rompan la codificación enemiga, sienten las bases de la informática y todo lo que decíamos antes, en cambio, venimos escasos) hasta el que cree en el absolutismo de las leyes diciendo que Turing rompió las leyes vigentes en su época y que por lo tanto las disculpas no son necesarias. La misma lógica que nos llevaría a concluir que Kaltenbrunner no rompió las leyes vigentes en su época por lo que su condena fue injusta.

Turing, como Oscar Wilde años antes, fue condenado por gay. Así de ridículo, así de inadmisible. Hace unos pocos días, Gordon Brown se disculpó por la condena. No va a traer a Turing ni a todos los que han sufrido semejante injusticia de vuelta, ni siquiera va a salvar a los que las sufren hoy en varios lugares del planeta, pero aún así es un paso necesario: que un estado reconozca los abusos que ha cometido, y los reconozca como abusos es una condición necesaria para que no se repitan (dije 'necesaria', no 'suficiente')

Por estar guiada por imbéciles, la humanidad perdió todo lo que Alan Turing podría haber dado para mejorar nuestra vida (no me cabe la menor duda que los avances científicos son el factor que más incidencia tiene en nuestra calidad de vida). Terrible para el pobre Alan, pero un castigo castigo justo .

(*)
sí, claro, los polacos lo hicieron antes, solo que muchas veces tardaban más tiempo que el que tardaban las órdenes en volverse obsoletas... y el objetivo de la criptografía no es hacer ilegible el mensaje desde acá hasta la muerte térmica del universo, sino que el tiempo requerido para romper el código haga la empresa inútil

Sunday, September 20, 2009

La crisis como oportunidad

- En la moto la carrocería sos vos
- El problema que tenemos es que no hay documentación
- Acá lo que hace falta es calidad institucional
- Acá el problema es el clientelismo político
- Lo que sucede es que el gobierno no quiere mejorar la educación para gobernar un pueblo ignorante


Podría seguir citando frases así de pelotudas, pero mi preferida es la del título. Me gusta, me fascina esta frase tan común entre vendedores de cursos, libros y seminarios que nos entregan la verdad revelada, que se revela, precisamente, como un par de obviedades genéricas escondidas detrás de un lenguaje altisonante. Creo que le gana a las boludeces que puede decir mi abuela, a las de un project manager medio burócrata, a las que dicen periodistas analfabetos funcionales dedicándose temas que superan su capacidad de análisis y formación, o incluso a las que dice un tachero (conductor de taxis) haciendo análisis sociológicos.

"La crisis como oportunidad" es un título que copa seminarios, artículos de revistas de negocios, cursillos y demás timos cuando empiezan a asomar las primeras amenazas de crisis. No creo que sea para sorprenderse, al fin y al cabo la crisis también afecta a los vendedores de amuletos y brujerías, aunque, claramente, menos que a los vendedores de cosas realmente útiles.


La frase en cuestión se basa, supongo, en una idea con algo de lógica: una crisis cambia el statu quo de un sistema, lo sacude un poco, hace caer a quienes tenían lugares establecidos y eso abre espacios que antes estaban cerrados. Puede que el mecanismo base funcione, pero tomarlo con el optimismo que intentan desplegar quienes titulan así sus trabajos se asemeja a pensar, en el medio de un terremoto, 'que bueno! en el futuro habrá más plazas y espacios verdes!". Los espacios se abren con sangre y muertos y antes de alegrarnos livianamente conviene pensar si vamos a contar cadáveres o vamos a ser uno.

Decía, puede que sea cierto que en las crisis es donde se puede ganar más. Lo podemos ver pensando en el inversor que compró propiedades en argentina en 2002 y las vendió en 2007. Cuando hacemos retrospectivas pensamos que lo que terminó por pasar era inevitable y que deberíamos haberlo sabido: pero no estábamos condenados al éxito en 2002, ni siquiera estábamos condenados a los sojodólares que entraron en malón entre 2003 y 2007 y crearon lo que crearon. La crisis fue una oportunidad, sí, pero los espacios se abrieron estaban regados de sangre, sufrimiento, quiebras, desempleo y pobreza. El hecho de que, pasada la crisis, tendamos a pensarla solo como oportunidad (o a sobrevalorar ese aspecto) se explica un poco por el sesgo de retrospectiva.

En realidad, este post esta recorrido por una pregunta. Digo, yo, que usualmente (al menos en persona, ignoro la imagen que doy en este blog) parezco un tipo con opiniones bastante establecidas, no estoy seguro de que papel podría jugar el optimismo en nuestro desarrollo y crecimiento. Conviene ser el optimista que ve la crisis como oportunidad? O es mejor tener los pies sobre la tierra y recordar que la sangre que riegue una nueva oportunidad podría llegar a ser la propia?. Cuando uno escucha a los triunfadores, ese grupo tan difusamente definido (o en realidad, cuando se habla de ellos), se recuerda que fueron gente optimista, que siempre creyó en su triunfo. Por supuesto que se trata de un problema de sesgo de selección: por cada optimista triunfador hay unos cuantos optimistas en el cementerio... Aún así, la pregunta persiste.

Wednesday, August 26, 2009

Muchos Mitos

Como comentaba hace un tiempo, estoy trabajando con Sql Server. Eso no solo implica cambiar de motor y olvidar algunas cosas que en Oracle estaban desde la década pasada (me olvidaba de una en el post anterior: poder hacer inserts masivos desde variables en memoria, y poder hacer updates masivos a secas), sino también cambiar de comunidad, leer otros libros, otros blogs, hablar con otra gente.

Además de mi pequeño berrinche por perder algunas features que me han gustado, he notado algo peor: la comunidad de Sql Server es notablemente más pobre que la comunidad de Oracle. Y no lo digo porque no haya personas como Tom Kyte, Craig Shallahamer, Jonathan Lewis o Cary Millsap (porque, por ejemplo, Kalen Delaney evidentemente sabe de que habla), sino porque hay un concepto que en la comunidad de Oracle está bastante claro y que la de Sql Server no parece haber descubierto: la gestión de performance por índices agregados no sirve. Pareciera a veces que a los muchachos de Sql Server les falta leer a Neil Gunther.

Los libros de performance de Sql Server que estoy leyendo insisten, todos, con la vieja y ridícula idea de hacer una linea base de indicadores cuando tu sistema anda bien y luego detectar desvíos sobre esos indicadores, así, de alguna manera, detectarías los problemas de performance antes de que sucedan viendo los síntomas antes de que se manifiesten en el ambiente productivo. Y cuando tenés un desvío, apretás el botón rojo ponés la batiseñal en el cielo y al rato vienen superman y linterna verde (bueno, nadie es perfecto) a rescatarte.

Esta idea tiene varios problemas. Diría que esta idea solo tiene problemas. Y en todos los niveles. Empecemos.

Primero, establecer una linea base de indicadores cuando tu sistema anda bien es una quimera, por varias razones: a veces llegás, como consultor experto en performance, como DBA, como arquitecto, como galeote o lo que fuera a algún lugar donde, si las cosas anduvieron bien, vos jamás las viste. Otras, el sistema cambia lo suficiente como para que la línea base se desactualice antes de que tenga validez estadística (esto implica mayor funcionalidad que implica más carga que requiere una actualización en hardware: o dicho de otra manera, el software cambia). Y a veces (esto es particularmente cierto en las puntocom), no se necesita que cambie el sistema, tan solo cambia el patrón de uso por alguna condición comercial o del entorno.

Otro problema tiene que ver con que el conjunto de indicadores de un sistema corriendo no es un sistema de ecuaciones con solución única. Es decir, que un sistema puede andar bien con varias combinaciones de indicadores. El único indicador razonable para medir la performance es el tiempo de respuesta en relación a la carga de trabajo: si el resto cambia pero mi tiempo de respuesta es razonable, entonces está bien independientemente de lo que diga el hit ratio, la tasa de inserción, la cantidad de log file syncs (o como se llamen en Sql Server) o lo que fuera.

Por último (cerrando los problemas que se me ocurren ahora, no pienso poder abarcarlos todos), muchas veces los indicadores no sirven para nada. El indicador más exitoso en esto de no tener ninguna utilidad práctica es el hit ratio (calculo que porque es el más fácil e intuitivo). Cary Millsap explica por qué el hit ratio no es un buen indicador, demostrando que un hit ratio muy alto puede ser problemático. Particularmente nunca vi un caso así, pero sí vi bases con hit ratios 'bajos' (de alrededor del 70%) que soportaban sistemas que escalaban muy bien y con excelente tiempos de respuesta.

El problema con el hit ratio es el viejo problema de confundir correlación con causalidad. A veces, ciertos problemas que degradan la escalabilidad y los tiempos de respuesta, también bajan el hit ratio, lo que no quiere decir que todos los problemas de performance lo hagan ni que un hit ratio menor al 90% solo pueda ser causado por algún problema. Lo mismo se aplica a cualquier indicador.

Millsap usa el siguiente ejemplo: supongamos dos conjuntos de consultas que obtienen exactamente el mismo conjunto de datos. El primero luego de correr en un sistema tiene un 99% de hit ratio y el segundo un hit ratio de 90%. Es mejor el primero?. Depende: supongamos que el primero hizo 10000 lecturas (entre lógicas y físicas) y el segundo 100. Millsap aclara que "el hecho de que acceder a memoria sea 10000 veces más rápido que acceder a disco no significa que una lectura lógica (resuelta en el caché) sea 10000 veces más rápida que una lectura física (en los datafiles)". Más aún, si tenemos consultas que leen inecesariamente una y otra vez los mismos bloques, el hit ratio será alto.

Por supuesto, mis rápidos comentarios sobre el artículo de Millsap no son excusa para no leerlo. Incluso si no se trabaja con Oracle, los conceptos se aplican a cualquier base de datos.

Resumiendo, los mejores indicadores (debería decir 'únicos indicadores') de la performance de un sistema son sus tiempos de respuesta y su capacidad de escalar, no un hit ratio o una esotérica combinación de indicadores. Ignoro cuanto tiempo tardará la comunidad de Sql Server en darse cuenta de esto. Tal vez cuando tengan que soportar un volumen realmente alto.

Monday, August 17, 2009

El mejor argumento

Me gustan los debates filosóficos. Y me gustan, entre otras cosas, porque a diferencia de las discusiones en donde hay algo en juego (como en el trabajo, en política o en la ética aplicada, por ejemplo) se pueden mencionar los buenos argumentos del contrincante sin arriesgar nada.

Puedo, por tanto, mencionar el mejor argumento de los que creen en la hipótesis dios. Por supuesto que no me refiero a uno al que le importamos y que, como diría Mark Twain, ronronea como un gato mimoso cuando escucha que le dedican horribles cantos desafinados. Me refiero al 'gran diseñador indiferente': ese que estableció las reglas y se desentendió del asunto y que es tan imposible de demostrar como de negar y cuyos efectos en la realidad serían perfectamente imperceptibles (dice Leonardo Moledo a coro con Gregorio Klimovsky, con mucha razón, que no existen diferencias prácticas entre creer en este último dios y en ninguno).

Tengo que hacer un esfuerzo para cortar las digresiones, que si hay un tema que las favorece es este y mencionar el argumento: la irrazonable efectividad de las matemáticas en las ciencias naturales. Este concepto fue propuesto por Eugene Wigner, maravillado ante la increíble manía del universo físico de dejarse modelar por construcciones matemáticas. La matemática es algo que construimos nosotros, decía Wigner, y por lo tanto es asombroso que el mundo físico, que nosotros no creamos, se explique tan bien por ella. Alguien, concluye Wilder, nos ha dado un regalo (inmerecido, se apura a aclarar en un arranque de modestia religiosa) magnífico: que una construcción humana explique aquello que los humanos no creamos. Alguien nos ha dado una sutil, hermosa, y maravillosa pista de su existencia. Casi que me gustaría creer en un dios con tan buen gusto y tan sofisticado, que gusta de dejar hermosas y crípticas pistas de su existencia.

Razones para maravillarse no faltan. En muchos casos (no me animo a decir 'en casi todos' por falta de conocimiento), la construcción matemática precedió a la utilización física. Einstein estaba buscando una construcción matemática para modelar sus espacios curvos y se encontró con un trabajo de Gauss que tenía, en ese momento, doscientos años y que no era más que un jueguito matemático. Otro ejemplo asombroso es el de Werner Heisenberg que encontró un modelo para explicar las transformaciones cuánticas: la aritmética de matrices, que existía como jueguito matemático desde, por lo menos, ciento cincuenta años de Heisenberg (y de la sospecha de la teoría cuántica).

Me gusta el argumento, y me parece el mejor de los argumentos a favor de la existencia de dios. Aún así, creo que no es suficiente. Siento vergüenza al meterme en un debate que supera mi capacidad y formación por bastante, pero creo que el realismo matemático es la explicación correcta: la matemática no se inventa, sino que se descubre. Y como la matemática existe en la realidad (se descubre), puede demostrar el asombroso paralelismo que demuestra con la física sin la existencia de ningún generoso y sutil dios que nos permita describir el universo con un invento nuestro.

Si existiera una civilización extraterrestre lo suficientemente avanzada como para tener ciencia, crees que tendrían una matemática igual o distinta a la nuestra? me preguntaron una vez. Mi respuesta fue que 'tendrían la misma, naturalmente', y en ese momento me convencí que la única forma de que tuviéramos una matemática idéntica sería que ésta exista en la realidad. Aunque yo hubiese preferido que la matemática se derivara de la lógica formal, el realismo matemático tenía el terrible atractivo de refutar el mejor argumento a favor de la hipótesis dios.

Por supuesto, el efecto de la irrazonable matemática se da en la física y las ciencias con base física (química, por ejemplo). Nada dice que se de en la economía. Entre otras cosas, porque la irrazonable es la economía y no hay ninguna efectividad en ella que nos asombre.

Sunday, July 19, 2009

Ombligología

O el arte de mirarse el ombligo. Si hay algún lector, sirva esto de advertencia.

Andrés me ha pasado un meme. Hasta este preciso momento, la única definición que venía a mi cerebro cuando alguien pronunciaba la palabra meme era la metáfora propuesta por Richard Dawkins para explicar el concepto de selección natural en un contexto no biológico. Otro ejemplo de selección natural no biológica ha sido el propuesto por el inconmensurable Stanislav Lem en su magnífica novela (permítaseme la redundancia: magnífica novela de Stanislav Lem es redundante) Invencible. No viene al caso, pero siempre está bueno recomendar a Lem.

Pero volvamos a los memes: Richard Dawkins se propone demostrar que el mecanismo de selección natural sobre unidades de replicación pequeñas que sufren variaciones aleatorias funciona perfectamente, y no solo en la biología. Para eso toma como unidad de selección las ideas o conceptos: los bautizó 'memes' y propuso un mecanismo de replicación de los memes mejor adaptados. Ojo, no se trata de los memes más benéficos, sino de los mejor preparados para su propia supervivencia: los memes (o ideas, o prejuicios, o conceptos que albergamos) pueden ser perjudiciales para nosotros, sus anfitriones... tal como la conducta cortoplacista que nos sale tan naturalmente nos pone en peligro.

El concepto de meme después lo tomaron Susan Blackmore, Daniel Dennett y otros más. Dawkins, después de algunas idas y vueltas, parece haber aceptado con gusto que su metáfora sea la base del desarrollo de una nueva teoría, de acuerdo a lo que dice en 'El Capellán del diablo'.

Yo creo que la metáfora de los memes es algo más que una buena metáfora. Digo, al fin y al cabo seguimos creyendo (la primera persona es retórica, por cierto) en un señor de barba muy poderoso que se preocupa por lo que hacemos y que está dispuesto a premiarnos y a castigarnos. Pero prometí alejarme de terrenos procelosos en este blog, y en el próximo post me dedicaré a otro mito, muchos menos nocivo que el mentado de pasada más arriba.

Ahora, al punto sobre el meme de Andrés: que puedo ser?. No se, diría. A mi edad, pasados los 30, no tengo derecho a conjeturar que puedo ser algo que no soy (no dije 'a lograr algo que no logré', dije 'a ser algo que no soy'). Y que soy?. Bueno, a veces soy demasiado negativo, tengo gran facilidad para ver las fallas en lo que miro. Tampoco soy de una única manera siempre, pero a veces soy irritable. Me irritan las frases hechas, me irritan los eslóganes y los pensamientos de peluquería (y me irritan porque se escapan de las peluquerías), soy sarcástico y a veces me vuelvo ofensivo. Y como este blog en anónimo, también puedo hablar bien de mí sin que sea pedantería: soy un buen integrante de casi cualquier equipo, soy hábil en lo que hago (y en casi nada más), puedo abstraer conceptos y tirar relaciones razonables entre conceptos aparentemente alejados, y soy un buen autor de metáforas. Claro que para buenas metáforas, están los libros de Stanislav Lem... ya lo recomendé antes?

Saturday, July 11, 2009

Yo no hago eso en público

"Math is like sex. It's something you shouldn't do in public."
--K. Cunningham (estuve toda la semana diciendo que era de Daniel Dennet. Y no se quien es Cunningham)

"Physics is to mathematics as sex is to masturbation"
--R. Feynmann (de esta estoy seguro)


La verdad es que de ambas frases, solo la primera viene a cuento. La segunda la agrego porque me gusta la comparación, y porque me gusta la matemática. Incluso, no veo en la frase ningún contenido peyorativo hacia la matemática: está claro que es la base de la física, y no podés ser un buen físico si no manejás razonablemente bien la matemática. Es decir, la comparación de la frase es perfecta.

Pasada esta pequeña introducción algo adolescente, puedo ir al punto: me encontré estas últimas semanas con un tipo de personaje, simpático si tenemos suerte, insoportable la mayoría de las veces: el matematicofílico. Este curioso personaje no puede dejar de vocear, casi diría de apostar, las complejidades de los algoritmos que ve por ahí. Es capaz de gritar, desde tres escritorios de distancia 'ese algoritmo tiene complejidad (n)* log(n)!!'. Por supuesto, nadie tiene ganas de ponerse a analizar sus afirmaciones.

Me queda claro que nadie determina en cinco segundos la complejidad de un algoritmo, al igual que nadie puede formalizar un problema combinatorio en cinco segundos. No importa, el matematicofílico es capaz de hacer ambas cosas: puede gritar 'eso es una combinatoria sin repetición de 4 en 8!', o puede proferir el grito de guerra del algoritmo que mencionaba antes, y salir de la discusión, contento de haber sido capaz de iluminarnos con su sabiduría, sabiendo que ahora tenemos una luz para guiarnos a hacer software más performante. Gracias totales.

He encontrado más de un tipo de matematicofílico: desde el chanta absoluto (el otro día, mi amigo P. me hacía acordar de A., uno que calificaría de chanta e indeseable) hasta este que inspiró el presente artículo, que cuando programa lo hace bien, que es un tipo que realmente sabe de informática y que ha cursado la mejor carrera de informática que se da por estas pampas.

De todas formas, existe un pequeño detalle: en este caso, el matematicofílico le pone un parche primoroso a algo que son solo harapos. Y pone la energía en el lugar equivocado. Me explico: el software que solemos hacer, sin ser CRUD crudo, se lleva la parte del león del procesamiento en la base de datos. Del tiempo total de las transacciones, un porcentaje abrumador se consume en la base de datos. Más aún, la base de datos (estamos hablando de MS SQL Server, pero lo mismo sería cierto si estuviéramos hablando de Oracle con su maravilloso RAC) es el componente con escalabilidad horizontal más complicada.

El matematicofílico entonces, decía, gasta su energía en optimizar una parte pequeña del problema, mientras descuida las cagadas que hacen los programadores
cuando acceden a los datos, él incluido, que es bueno cuando hablamos de generar código.

Ignoro por qué, pero el patrón de pensar la base de datos como una caja negra misteriosa que, no importa lo que hagamos, siempre responderá igual está extendidísimo. Y no hablo de los malos programadores, sino de los buenos. El origen de ese problema?. Ni idea.

Monday, June 15, 2009

Enamorándome

Disclaimer: post técnico.

El oráculo siempre me ha parecido la base de datos que, por mucho, aventajaba a sus competidores. Por esas cosas del fanatismo, tenía pocos argumentos porque siempre había trabajado con Oracle, salvo algunas cortas pesadillas donde mi disgusto por la nueva base podía tener que ver más con mis costumbres y hábitos que con la diferencia real entre ellas.

Ahora, trabajando con Sql Server, mi gusto por Oracle se está transformando en enamoramiento. Enamoramiento, claro, como el de un tanguero: llorando por lo perdido. O como canta Serrat, no hay nada más amado que lo que perdí.

Y que perdí?. Esto perdí:
  • En Oracle, de toda la vida, un lector no se bloquea porque otro proceso escriba. Sql Server lo incorpora a partir de 2005. Antes, si queríamos hacer que un lector no se bloqueara por un escritor podíamos leer los bloques sucios (no comiteados).
  • En Oracle, el profiler no agrega carga adicional, tanto que si no fuera por el espacio en disco, uno lo podría tener siempre prendido.
  • En oracle el profiler da datos agregados y también da un listado de los eventos generados por esa sesión: por ejemplo, puedo ver una línea por cada bloque que leyó una consulta, viendo a que tablespace fue. En Sql Server solo tengo valores agregados por consulta. Y que para que quiero ver a donde leyó cada bloque?... por ejemplo para saber si está yendo al rollback (o a la tempdb en Sql Server) para leer consistente. Como me entero en el profiler de Sql Server si el problema es que un stored procedure está recibiendo parámetros innecesariamente largos y la demora está en la transferencia de red? (cosa que me ha pasado en Oracle). Más genéricamente, la comunidad de Sql Server parece que todavía está haciendo análisis de performance por indicadores (tema para otro post, mientras tanto, se puede leer online el primer capítulo del libro de Cary Millsap , particularmente la página 6).
  • En Oracle, existe un paquete, llamado DBMS_STATS (por cierto, si googlean algo de Oracle y caen en oracle-dba.com dba-oracle.com (*), sepan que su autor sabe muy poco de lo que habla), que permite generar estadísticas de las tablas para probar que plan elegiría el motor con otros, hipotéticos, juegos de datos. En Sql Server hay un mecanismo no documentado que permite exportar estadísticas de una tabla que ya existe. El mecanismo de Sql Server genera una larga sucesión de números en hexa que tienen codificados, de alguna manera y claramente inaccesible al resto de los mortales (muy Microsoft's way) las estadísticas. O sea, si querés sacarte una duda sobre una situación hipotética, esperá a que se produzca (sin mencionar lo incómodo que es pedirle al DBA algo cada cinco minutos)
  • Oracle tiene RAC, que no es un mecanismo de snapshots, por más que los admiradores de Sql Server lo intenten comparar con la replicación. RAC no es replicación de snapshots, RAC es un mecanismo por el cual varias instancias de bases de datos pueden acceder a los mismos archivos de datos. Y anda muy pero muy bien.
  • En Oracle puedo correr un debug contra los stored procedures sin necesidad de comprar un producto adicional. En Sql Server necesito una de las versiones de 'gama alta' del Visual Studio.
  • Oracle anda en varios sistemas operativos. Sql Server en uno (concedámosle ese status a Windows)
  • En Oracle, hay un UTL_MATCH, para calcular distancias entre strings que hasta implementa el algoritmo Jaro-Winkler. En Sql Server, claro, lo podés hacer.
  • En Oracle existe una API armada que incluye muchísimas funciones típicamente necesarias, en Sql Server se pueden hacer (con la extensión del CLR en 2005). Un ejemplo?... expresiones regulares (lo que ocurre, emho, es que los programadores windows se enteraron de la existencia de las expresiones regulares hace unos pocos años)
Supongo que habrá más diferencias, que iré disfrutando con el correr de las semanas.

Update: me comenta mi amigo P. que el dominio de la empresa de Burleson está mal, que el correcto es dba-oracle.com. En el link de su nombre hay un artículo de alguien que sí sabe sobre la ignorancia de este tipo. En la página de Jonathan Lewis hay bastante sobre Don Burleson.


Saturday, June 6, 2009

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.

Monday, May 25, 2009

Usted ya leyó esto en otras partes

En forma bastante predecible, las revistas (las que valen la pena leerse, digo, como el Scientific American, por ejemplo), los blogs (algunos que valen la pena leerse, y otros más parecidos a este blog), los programas de radio, los talk shows de la televisión, los realities y sus estrellitas que hasta el año pasado hacían mostrar el culo a alguna bonita golfa veinteañera se han volcado a preguntarse que ha fallado en nuestra comprensión de la economía para que hoy estemos aquí (bueno, tal vez haya sido demasiado adjudicarle esa preocupación a los últimos puntos de mi enumeración).

Las conclusiones son más o menos parejas: la economía tal como la conocemos dista de ser una ciencia, y no solo eso, difícilmente pueda considerarse una protociencia que al menos va bien encaminada. Los problemas de la economía (la ciencia económica, digo), vendrían básicamente del hecho de que la teoría de la elección racional no es ni siquiera una grosera sobresimplificación de nuestra forma de pensar, y de que, como dice Nassim Taleb, el único premio Nóbel (o algo así, para ser exactos ) de economía que ha recibido su premio por una contribución valiosa fue Daniel Kahneman. Precisamente, don Kahneman ha aportado pruebas convincentes de que nuestros sesgos cognitivos (que además, parecen ser innatos y, sin entrar en el debate nature vs. nurture, genéticos) impiden describir nuestro comportamiento por medio de formuleo matemático de la elección racional.

Como decía arriba, esto se convirtió en un tema más o menos recurrente en unas cuantas publicaciones. En el último número de Scientific American Mind hay dos artículos que tocan el tema. El primero de ellos es una entrevista a Peter Ubel, quien explica como nuestra tendencia al optimismo y al comportamiento manada (que mi vecino sacó un crédito? entonces puede que no sea tan peligroso!, que mi pareja se sirvió otra porción de postre? entonces a mí no me va a engordar tanto) puede arruinar nuestras finanzas personales (y globales), nuestra salud y más genéricamente, nuestro bienestar. Dice también Peter Ubel en un arranque de pesimismo (o elitismo? o derrotismo?, o vaya uno a saber qué) que un tercio de los norteamericanos adultos no son capaces de contestar cuanto es el diez por ciento de mil, y se pregunta como puede un tipo así evaluar el impacto de un posible aumento en las tasas de interés de interés en su hipoteca (una lástima que Ubel no cite fuentes de esta afirmación)

El segundo artículo no toca el tema directamente, es más una explicación (detallada y ejemplificada) de cuan malos somos al evaluar probabilidades, y de cuanto esfuerzo, entrenamiento y concentración requiere hacerlo bien. El ejemplo elegido es la evaluación de las probabilidades de tener una enfermedad dado un resultado positivo de un análisis para detectar dicha enfermedad. El ejemplo es usado también por Leonard Mlowdinow en 'The drunkard's walk' y por John Allen Paulos en 'Innumeracy'.

El asunto es así: Supongamos que nos hacen un análisis de HIV. Usan primero el método Elisa, que tiene un índice de falsos positivos del 1%, aproximadamente. Supongamos que el test da positivo... cual es la probabilidad de que en realidad estemos sanos? (o de que en verdad estemos enfermos?). Cual es? Si hay algún lector... tiene un número?

La respuesta es que en el párrafo anterior faltan datos para decidir: la respuesta no es que hay 99% de probabilidades de que estemos enfermos, ni nada por el estilo. Para llegar a la respuesta nos falta un dato: la prevalencia (el porcentaje de gente que sufre la enfermedad) de la infección. Para derivar la respuesta, tomemos la prevalencia global del HIV estimada para Argentina (0,31%).

Bien, ahora para hacer números redondos, supongamos que se han hecho en nuestro laboratorio 320 análisis de HIV. Como la incidencia es del 0,31%, eso da que nuestro laboratorio encontró un caso positivo (vamos a asumir que estamos en el caso más probable, esto es estadística, nada dice que deba ser así en todos los casos), ya que el 0,31% de 320 es 1.

Ahora, de esos 320 casos, alrededor de tres tipos se llevaron un test positivo sin serlo. O sea, de cuatro test positivos, uno es un positivo real y los otros tres son falsos positivos. Por lo tanto, hay un 75% de probabilidades de que no tengamos nada. Si a esto lo corregimos por incidencia demográfica y de comportamiento la probabilidad es menos (sonará feo, pero si somos una persona que no usa drogas endovenosas y que no tiene sexo sin protección o es monógama, las probabilidades de estar infectado bajan: no a cero, pero bajan).

Quiere molestar a su médico, estimado lector (si es que hubiera algún lector)?. Bueno, si es así, la próxima vez puede preguntarle cual es la probabilidad de que un resultado positivo de un determinado análisis no sea en verdad un falso positivo dada la incidencia?. El médico, en medio de una consulta por obra social mal paga, apurado porque se ve obligado a que su consultorio funcione como un McDonalds, raramente disfrutará de su sentido del humor.

Friday, May 15, 2009

Modelos de espera

Por motivos que no vienen al caso, el otro día estaba repasando las herramientas y papers que tengo en mi notebook y que pueden llegar a ser útiles en el trabajo. Pienso que hay una, que he usado en los proyectos de mejora de performance (mi pasión oculta, y algo así como el premio consuelo: puedo jugar a detective sin trabajar para House o sin dedicarme a la investigación) que bien vale un post.

La herramienta es tan simple como una planilla excel que se basa en la idea de que un sistema que atiende transacciones en, en definitiva, un modelo de colas. La idea del modelo de colas es bastante simple:
  • Existen una cantidad variable de recursos que atienden peticiones (canales).
  • Los clientes arriban al sistema y si no hay un recurso que atienda espera poniéndose en una cola.
  • Los canales demoran en atender cada cliente un tiempo variable descrito por una función de probabilidad.
  • Los clientes arriban al sistema en intervalos variables descriptos por una función de probabilidad
Los cálculos que yo conozco se basan en sistemas donde la disciplina de la cola es FIFO, la distribución de los arribos se describe como un proceso Poisson caracterizado por la tasa de clientes arribados sobre unidad de tiempo. Los tiempos de servicio de los canales (lo que tarda cada canal desde que la petición entra el canal, no a la cola, hasta que sale) se describen por medio de una distribución exponencial. Se puede complicar más ( impaciencia de los clientes, otras disciplinas de espera ) pero usualmente el modelo básico es suficiente para analizar un software up&running.

Prácticamente, no me he encontrado con un sistema que no pueda ser modelado como un sistema de colas:
  • Un sistema web recibe peticiones (los GET y POST HTTP) que son atendidas por threads que corren en el application server. Los threads son los canales de atención y si no hay un thread disponible, la petición espera.
  • Un proceso batch procesa peticiones (transacciones) que esperan en cola hasta que el proceso puede atender a la próxima.
  • Una base de datos que recibe DML es tiene una serie de procesos que atienden las peticiones
Encuentro particularmente útil el modelo de colas no para reemplazar al test de stress de un sistema, sino para complementarlo. Así, luego de terminar el test de stress o de mirar en producción un rato puedo contestar fácilmente preguntas del tipo:
  • Que sucedería si mi sistema recibe el doble de peticiones y hago un esfuerzo (en rediseño) para que el tiempo de servicio no aumente más del 10%?
  • Si espero un determinado incremento en la carga de transacciones, cual debería ser mi optimización del tiempo de servicio para obtener un determinado tiempo libre del canal (para tareas administrativas, por ejemplo).
Craig Shallahamer tiene un excel de un modelo de colas en su web (en el link hasta que Craig decida rediseñar su página). Es una modesta maravilla que en la primer solapa requiere la introducción de los valores característicos y en las siguientes muestra la evolución del sistema con variaciones de los valores característicos.

Así que la próxima vez que un cliente, con cara de ‘ahá, acá te cagué, consultor’ pregunte: 'y de donde sacaste que si la carga de transacciones aumenta un 20% me quedo sin tiempo para el backup', uno puede sacar las planillas y agobiarlo con una clase de investigación operativa ligera.

Y como bien saben los economistas, mostrar números y matemática razonablemente avanzada da un aura de respetabilidad. Aunque todo esté construido sobre nada. En realidad, el modelo de colas sí funciona para el análisis de performance de los sistemas informáticos, simplemente tenía ganas de hablar mal de los economistas. Porque (y con el solo objeto de divertirse un rato con una buena lectura y sin que tenga relación con el post) como bien señala Leonardo Moledo, con la economía es otra historia.

Friday, April 3, 2009

Vendiendo Indulgencias

Me entero que han ingresado en la legislatura de la ciudad de buenos aires dos proyectos para la colegiación de los profesionales que actúan en el ámbito de la ciudad, lo que incluye, claro, a los informáticos.

Lo que sigue es un juicio de intenciones, cosa que convendría no hacer, pero creo que cuando la mala leche es tanta y tan mala, hay pocas alternativas.


Entiendo que hay dos clases de personas que apoyan la colegiación:


  • El primer grupo está compuesto por un grupo de inútiles que pretende vivir de vender indulgencias y de cobrar la matrícula de quienes sí trabajamos y tenemos como norte seguir haciéndolo (o dejar de hacerlo por un método más decente, como ganar la lotería, pegarla con una acción o asaltar un banco).
  • El segundo grupo está compuesto por un grupo algo mayor que el primero. El de aquellos que se sospechan, con razón o sin ella, no muy buenos en lo suyo y esperan que achicando el denominador sus probabilidades mejoren: es decir, esperan que eliminando la competencia en base a criterios que poco tienen que ver con la habilidad laboral su situación en el mercado mejore. Ahora se me ocurre que hay un subgrupo dentro de este grupo: aquellos que no se sienten poco hábiles, sino que sienten que el mercado no reconoce sus increíbles habilidades. Esperan, por este medio, que se instrumente un mecanismo por fuera del mercado para corregir semejante injusticia: me contratás a mí no porque te parezca más hábil, sino porque tengo matrícula.

Puede que exista un tercer grupo: aquellos que están honestamente convencidos que la matriculación mejorará el nivel profesional (y de profesiones que piden a gritos una mejora en el nivel, como la informática). Agrego este grupo no porque tenga pruebas de que exista, sino por seguir la regla de que la ausencia de evidencia no es evidencia de la ausencia. Pero sí, no encuentro evidencias de que este grupo exista.


Podría argumentar por qué no creo que sirva un colegio, y los argumentos irían en estas líneas:


  • No hay evidencia de que las estructuras burocráticas mejoren el nivel académico e intelectual, y si hay evidencias de lo contrario.
  • No es ni justo ni conveniente decirle a una empresa a quien puede contratar y a quien no.
  • Con respecto a la responsabilidad legal por mala praxis profesional que pudiera resultar en problemas para terceros, se puede resolver sin colegio: los médicos en la ciudad de buenos aires no tienen colegio y responden legalmente por sus malas praxis.
  • No quiero pagar matrícula en forma obligatoria.
  • No me parece justo que me obliguen a no contratar a los excelentes profesionales que conozco que no tienen título universitario (da la casualidad, los dos mejores que conozco no tienen título).
Pero no voy a desarrollar estos argumentos, porque estaría sucumbiendo a la falacia de la inversión de la carga de la prueba. La carga de la prueba la tiene quien afirma, por lo que son quienes proponen el colegio quienes deben demostrar para qué serviría y como lograría los objetivos. Hasta donde vi, están lejos de lograr este objetivo.

Leía el proyecto de Martín Borrelli, legislador por el PRO y titular del Partido Federal de la ciudad de buenos aires ( la melange ideológica del nacional-conservadora-economicoliberal-malvinera de su partido es realmente divertida, si es que fuera una broma de Peter Capusoto). El asunto empieza bien, dice:


No es ocioso recordar que aprobada la colegiación, la matriculación se vuelve obligatoria y con ella, la imposición de aranceles o contribuciones para el ejercicio de la profesión y el sostenimiento de las estructuras burocráticas del nuevo colegio. Allí donde antes no había nada, ahora florecen oficinas, cursos y empleados. Allí donde imperaba la autorregulación, aparecen los tribunales de disciplina para imponer sanciones.

Bravo! Ese texto es un verdadero liberal, pensé. No es que coincida en todo con un verdadero esco… liberal, pero se trata de una posición intelectual con innegable valor, pero bueno, este no es el caso (este tampoco es el caso, debería decir) . Sigue:


Sin el debate necesario los colegios profesionales se convierten en una herramienta de pocos, en botines de grupos dominantes, en especulación electoral, y el mérito o conveniencia de su creación deja de ser la de los sujetos de regulación de dicha ley –los propios profesionales- para transformarse en una cuestión de mera oportunidad convalidada por la Legislatura y sus mayorías ocasionales.


Bueno, acá se le empiezan a ver las plumas: el problema no es la imposición de aranceles y contribuciones, ni la existencia de burocracia ni un tribunal de notables diciéndole al mercado que carajo tiene que hacer, no. El problema es que sea un botín algunos. Un pensamiento notable por lo contradictorio: no es malo el concepto de que alguien se apropie de una actividad, lo malo es que alguien se apropie de la actividad en la vida real.


Para evitar eso que, con justa razón, identifica como pernicioso, propone crearlo. Luego de la necesaria discusión y consenso, claro.
Alguien sigue su fuzzy logic?, yo no.

El lunes 6 de Abril, en en el Anfiteatro 3 de la sede Las Heras de la FIUBA habrá una reunión al respecto.

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)

Friday, February 27, 2009

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.

Friday, January 30, 2009

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.

Tuesday, January 20, 2009

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.

Friday, January 2, 2009

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.