Un Punto Azul Pálido

El castigo justo

2009-09-26T12:35:00.000-07:00

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

La crisis como oportunidad

2009-09-20T19:21:00.000-07:00

- 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.

Muchos Mitos

2009-08-26T15:53:00.000-07:00

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.

El mejor argumento

2009-08-17T17:21:00.000-07:00

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.

Ombligología

2009-07-19T13:04:00.000-07:00

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?

Yo no hago eso en público

2009-07-11T15:10:00.000-07:00

"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.

Enamorándome

2009-06-15T13:53:00.001-07:00

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.

Entidades invisibles

2009-06-06T14:51:00.000-07:00

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.

Usted ya leyó esto en otras partes

2009-05-25T14:24:00.000-07:00

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.

Modelos de espera

2009-05-15T19:34:00.000-07:00

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.

Vendiendo Indulgencias

2009-04-03T08:34:00.000-07:00

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.

Ingenieros, artesanos o la reserva moral de las organizaciones?

2009-03-27T14:01:00.000-07:00

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

2009-03-04T07:22:00.000-08:00

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

2009-02-27T05:50:00.000-08:00

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

2009-01-30T12:17:00.000-08:00

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

2009-01-20T12:56:00.000-08:00

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

2009-01-02T10:27:00.000-08:00

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

2008-12-19T09:23:00.000-08:00

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

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

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

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

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

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

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

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

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

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

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

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

Oportunidades perdidas y mejoras inesperadas

2008-12-17T06:36:00.000-08:00

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

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

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

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

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

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

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

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

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

Tengos unas cuantas cosas para hacer...

2008-12-04T09:37:00.000-08:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inteligentes y Creativos

2008-11-24T09:22:00.000-08:00

Todos queremos ser inteligentes, aún cuando haya algunos problemitas para definir qué cosa es la inteligencia, suponiendo que esta sea una sola cosa. Steven Pinker en su imprescindible libro The Blank Slate da una lista de habilidad cognitivas innatas con las que nacemos

Podríamos (esto es delirio mío, Pinker es inocente) definir 'inteligencia' como el grado de habilidad que tenemos, en cada una de esas áreas, para sacar conclusiones acertadas, con datos limitados y, tal vez, tiempos acuciantes. Incluso, un tipo de inteligencia podría ser la capacidad para elaborar, a partir de nuestras 'intuiciones primarias', métodos para describir adecuadamente lo que nos rodea, muchas veces contradiciendo lo que nuestras intuiciones innatas nos hacen pensar.

Claro que además de inteligentes queremos ser creativos. Y como queremos ser creativos e inteligentes (nos han mostrado, con un montón de datos que sustentan esta idea, que la inteligencia y la creatividad tienen una alta correlación con el éxito) tendemos a ser abiertos cuando nos proponen métodos para aumentar nuestra creatividad e inteligencia.

Pero hay malas noticias: tal parece que no somos una tabla rasa (o un blank slate, de ahí el título de su libro): tenemos gustos, personalidades y, también habilidades innatas (y falta de habilidad innatas, también). Pinker es convincente, al menos, para quienes ya no pensábamos, al momento de tomar su libro, que existiera algo así como el alma y que, en definitiva, la mente es lo que cerebro hace, casi como la circulación es el resultado de la actividad del corazón.

Pinker es convincente. Si aceptamos el monismo (el materialista, claro), viendo la diferencia de habilidades corporales en los humanos, no encontramos razón para no pensar que también debe haber diferencia de habilidades intelectuales porque, al fin y al cabo, si estas últimas son fruto de la acción del cerebro su naturaleza no es muy distinta que la naturaleza de las primeras.

Decía que son malas noticias porque significaría que no podemos aumentar nuestra creatividad e inteligencia, solo la podemos desarrollar y entrenar, lo que podría llevar a una mejora de los resultados obtenidos, pero la limitación de hardware sigue estando allí, operando silenciosa, inflexible, y un poco cruel a veces.

Y la peor noticia para los que venden métodos para desarrollar la creatividad y la inteligencia es que no sabemos que cosas pueden desarrollar la creatividad y la inteligencia.

Sí sabemos que una persona inteligente o creativa puede sentir que no le conviene mostrar sus cualidades en determinados ambientes (si vamos por la pendiente resbaladiza, mala para argumentar pero buena para las metáforas, un campo de concentración no es un buen lugar para mostrar integridad intelectual, creatividad y predisposición a examinar críticamente a la autoridad, por ejemplo) y ese, me parece, es el limitado campo de acción de los métodos de la creatividad e inteligencia en la empresa.

Y por qué esto? Porque estos días estuvieron sobrevolando por acá, y por una ciclo de conferencias por lo demás muy bueno, algunos buitres que venden cursos y métodos (sin ninguna validez empírica, por supuesto) para hacer de todos nosotros gente creativa e inteligente, cuando la evidencia es que no tenemos una inteligencia que destaque y que somos bastante conservadores.

Las propuestas de esta gente siempre giran sobre lo mismo:

Toda Idea es Bienvenida, por lo que suponemos que la idea de que el HIV no existe o, en todo caso, no produce el SIDA, sino que es una conspiración del 'establishment médico' para vender drogas caras tiene el mismo valor que las ideas que han llevado al desarrollo de antiretrovirales que funcionan. Perfecto, no podría estar más de acuerdo.
Toda ocurrencia, imagen, recuerdo se debe expresar sin considerarla: obvia, insignificante, inmoral o ridícula. Toda idea ha de ser escrita, dibujada, sin autocensurarse. Impecable, agobiemos al prójimo con relatos pormenorizados de nuestra última partida de truco.
Toda crítica será pospuesta. Hay un momento para generar ideas y otro momento para valorarlas, evaluarlas. No censurar: cuando alguien propone que los planetas influyen en si la mujer (o el hombre) que nos gusta va a acceder a nuestro cortejo no se puede decir que es ridículo, porque, claro, sería censurar.
La cantidad de ideas es muy importante debido a que de antemano no se puede saber cual de las ideas puede resultar seleccionada, posteriormente, para resolver un problema o para encontrar una nueva solución. Eso! A sumar ideas!! Que tal vez vestirse pirata para luchar contra el cambio climático? (no, perdón, eso sí era una excelente idea. Ruego que Él se apiade de mi herejía)

Todo gira en torno a lo mismo, y puedo ver una (entre tantas otras) falacia: separar el proceso de emergencia de una idea del proceso de evaluación de la misma. Así, se supone (o supone esta gente) que es posible separar el proceso de ‘proponer’ del de ‘evaluar’. Tal vez se pueda, sí, y sea algo similar a la locura.

Pero bueno, se ve que no soy un tipo creativo.

Escuchábamos ayer

2008-11-19T10:31:00.000-08:00

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

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

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

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

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

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

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

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

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

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

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

La verdad en diez palabras

2008-11-12T10:41:00.000-08:00

Me encantan las frases motivadoras, los slogans (no, eslóganes), que pretenden ser enseñanzas demoledoras de como hay que ser, de como hay que pensar, de como hay que actuar. Me fascinan. Ejercen sobre mí el mismo atractivo que las soluciones sencillas y cortas, y no me dejo entristecer por el hecho de que tanta simplificación se haga al precio de la eficacia e incluso de la utilidad (y ni hablar del valor de verdad).

Pero mi gozo con las frasecitas aumenta con son atribuidas a alguna luminaria. Y en particular, cuando la atribución es falsa, o, al menos dudosa (así como Galileo es el santo patrono de los chiflados autocompasivos, Einstein podría ser el santo patrono de los amantes de las citas ridículas). Por eso, lamento que mi eslogan preferido ("lo único constante es el cambio", o algo así) no haya sido atribuido a Einstein. De todas maneras, no pierdo las esperanzas.

Aunque la frase "lo único constante es el cambio" nos suene a verdad de Perogrullo, actuamos como si esto no pasara, como si pudiéramos elegir que las cosas no cambien. En una profesión que gustamos de vender tan adicta al cambio vertiginoso que nosotros como nerds-geeks-geniales manejamos como nadie, gustamos de perpetuar algunos conceptos (como el de desarrollo en cascada, por ejemplo). Así, decimos cosas que han sido verdad hace millones de años (bueno, tal vez exagere) sin detenernos a pensar si son ciertas hoy.

Puedo entender uno de los motivos para este problema: uno no puede estar revisando permanentemente todo lo que ha aprendido. Y no es un problema que así sea, particularmente cuando hablamos de los conceptos de la base teórica (los BTrees andan más o menos igual desde hace unos cuantos años, por ejemplo), pero no estaría mal intentar recordar que las recetitas tecnológicas cambian con facilidad.

Por recetitas tecnológicas entiendo un tipo de pequeños mandamientos taxativos sobre como implementar, o sobre que cosas deben hacerse y que cosas no, que suelen propagarse a través de las versiones de una base de datos, sistemas operativos, lenguajes de programación y cosas así. Por ejemplo, "un cursor explícito es siempre más rápido que uno implícito", o "tenés que poner tus DML en procedimientos almacenados en la base", "tenés un full table scan, agregale un índice" y uno de mis preferidos: "no concatenes strings directamente, usá un StringBuffer".

El problema con estas recetitas tecnológicas es que suelen ser falsas, o, al menos, tienden a desactualizarse con facilidad (de las mencionadas, algunas fueron ciertas en algún momento y otras han sido siempre falsas o, al menos, discutibles). Más o menos me acostumbré a ellas y puedo explicar pacientemente a quien lo requiera por qué una recetita de esas es un mito (o puedo mandarlo a la entrada correspondiente de la wiki, para ser más honesto).

Si bien suelo ser paciente, el otro día perdí la paciencia. Un tipo que estaba tratando de convencerme de que debía comprar (que la empresa debía comprar, mejor dicho) un software propietario para inspección de código que no hacía mucho más que PMD, Checkstyles y Macker combinados me mandó una presentación de su maravilloso (según él) y caro (según el presupuesto) producto. En la segunda hoja del primoroso powerpoint los fabricantes de la herramientas tranquilizaban al lector diciendo que su herramienta era capaz de impedir que módulo, programa o similar que tuviera una query que hiciera un full table scan fuera a producción. Y luego, que detectaba problemas de performance como la concatenación de Strings en lugar del uso de StringBuffers. Esa presentación me convenció: la herramienta en cuestión hacía más cosas que la combinación de PMD + Macker + CheckStyles, el único problema era que las hacía mal.

De alguna manera, se les olvidó revisar sus conceptos sobre la performance de herramientas formados hace unos cuantos años, aunque pusieran en la presentación de su herramienta que "lo único constante es el cambio" (o algo así). Creo que estoy llegando a darme cuenta por qué me gustan los eslóganes: nos hacen pensar que actuamos como nos gustaría actuar, no como en realidad actuamos.

De esta anécdota surgió algo interesante. Nuestro embrionario detector de camelos informáticos (inspirado, claro, en el de Carl Sagan, y cuyo nombre más formal podría ser manual de procedimientos de verificación y validación de CMMI L3) incorporará algunas guías sobre como tratar las frases cortitas y taxativas no autoevidentes que parecen confiar en características ocultas o en internals de la tecnología: en el mejor de los casos, como algo que fue cierto alguna vez o es cierto en una versión muy específica y que debe tratarse con cuidado fuera de un ambiente muy definido (por aquello de la inevitabilidad del cambio). En el peor de los casos, como basura sin sentido.

Poder de Síntesis

2008-11-09T23:00:00.000-08:00

Our posturings, our imagined self-importance, the delusion that we have some privileged position in the Universe, are challenged by this point of pale light.

Our planet is a lonely speck in the great enveloping cosmic dark. In our obscurity, in all this vastness, there is no hint that help will come from elsewhere to save us from ourselves.

A Pale Blue Dot, Carl Sagan.

No recuerdo haber leído otro ningún otro párrafo con la abrumadora fuerza del copiado arriba. En unas pocas decenas de palabras sintetiza conceptos filosóficos, científicos y éticos con admirable arte, para terminar con una conclusión que aparece arrolladora, irrefutable y motivante: estamos en la oscuridad, en un universo algo hostil de tan indiferente, a solas con nuestra inteligencia, fuente de unas cuantas amenazas y peligros, a la vez que la única herramienta capaz de hacernos sobrevivir y, más aún, vivir mejor.

Creo que la ciencia no solo depara placer lúdico ( el placer de descubrir, que diría otro involuntario huésped de este blog), sino que la adopción amplia de su método y filosofía, más allá de los ambientes académicos, puede mejorar la sociedad en la que vivimos. Como copiábamos más arriba, estamos solos en esto, a merced de lo que buenamente podamos entender.

Puede que Carl Sagan no haya sigo uno de esos científicos que expanden el conocimiento, viendo algo donde los demás no vieron nada. Pero porque creo en la importancia social del conocimiento científico y del pensamiento crítico, creo que el aporte de Carl Sagan a la humanidad ha sido enorme, por más que su nombre apenas figure en las búsquedas de SpringerLink o no haya recibido un Nobel por haber revolucionado la forma de entender el mundo.

De todas formas, me animo a decir que en un sentido íntimo y subjetivo, sí ha tenido enorme influencia en la forma de entender el mundo. Por supuesto que no para los académicos, no si tomamos el cuerpo de conocimientos existente. Pero, en cambio, de alguna manera, ha logrado que la ciencia exista para mucha gente, la ha hecho visible e importante a los ojos de un público vastísimo y heterogéneo: sus libros han sido la íntima y personal revolución de la ilustración para muchos que los han leído, yo entre ellos.

El equipo de detección de camelos debería ser de portación obligatoria.

Ah, por cierto, hoy Carl Sagan cumpliría 74 años.

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

2008-11-03T08:53:00.001-08:00

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

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

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

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

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

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

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

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

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

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

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

Ilusiones y Certificaciones

2008-10-30T12:08:00.000-07:00

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

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

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

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

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

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

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

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

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

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

Tratamos de decidir

2008-10-24T10:24:00.000-07:00

Esta es una continuación del post donde contaba como nos habíamos hecho pasar por epistemólogos en pantuflas al momento de abordar el área de proceso de Decision Analysis and Resolution.

Las prácticas específicas de esta área son:

Establecer guías para el análisis de decisión (SP 1.1-1)
Establecer criterios de evaluación (SP 1.2-1)
Identificar soluciones alternativas (SP 1.3-1)
Seleccionar métodos de evaluación (SP 1.4-1)
Evaluar las alternativas (SP 1.5-1)
Seleccionar las soluciones (SP 1.6-1)

Más allá del mantra tenemos que cumplir con CMMI, intuimos que había (hay) una enorme oportunidad de apoyarnos en estos conceptos para mejorar la calidad de lo que producimos. Algo nos hacía (hace) ruido entre nuestra autovaloración y el resultado observado, aunque siempre hemos podido balancear la ecuación agregando un delta que sería la culpa de un tercero.

Todos confiamos en nuestras capacidades de decisión. Todos creemos entender que sucedería ante un curso de acción u otro ( sí, sí, ya se: tampoco escapamos al sesgo de creer que conocemos las variables y las opciones posibles, o dicho de otra manera, siempre vamos a tener el riesgo de ser engañados por la aleatoriedad ). Pero, como decía antes, el resultado nos empujaba hacia la acción: la realidad sugería que el proceso podía ser mejorado (muy mejorado, de hecho), porque más allá de nuestra confianza, los resultados estaban lejos de ser los que esperábamos.

El primer punto de la práctica habla de decidir que temas han de someterse al proceso formal de toma de decisiones (SP 1.1-1). No fuimos capaces de dar un algoritmo para determinar ante que situaciones comenzar con el proceso, y francamente no creo que lo haya. El gerente/líder/jefe de proyecto (o como quieran llamarlo) es insustituible por una máquina: va a tener que decidir que cosa es importante, clave o crítica.

Lo que sí fuimos capaces de hacer es de escribir ciertas obvias recomendaciones para definir que algo es importante, clave o crítico: si tiene un impacto no menor en atributos de calidad del producto, rentabilidad o tiempos del proyecto (que no son dos compartimientos estancos), o en las personas involucradas, es altamente probable que amerite el proceso de decisión formal.

Toda decisión se toma de acuerdo a cierto marco de referencia que prioriza determinadas cuestiones sobre otras. Ocurre que muchas veces (diría siempre, pero me contengo) no compartimos los marcos de referencia y de acuerdo a nuestras preferencias personales, experiencias, conocimientos y, sobre todo, posición en la organización, ponderamos mucho más ciertos factores que otros. Así se dan discusiones donde la seguidilla de argumentos y contra argumentos se hace interminable solo porque se discute presuponiendo un acuerdo en el marco valorativo. Una buena manera de evitar esto es que el marco valorativo fuera explícito (SP 1.2-1), e incluso, si fuera posible consensuado.

Todos pensamos, por cierto caracter de formación, que la explicitación del marco en términos cuantitativos sería preferible a una en términos cualitativos. Al final, se impuso la razón: los términos cuantitativos son deseables solo para aquello que sepamos cuantificar bien (performance, por ejemplo). No solo es inútil, sino también peligroso, andar poniendole números a las cosas sin ninguna base solo porque la matemática nos hace rendir ante su irrazonable efectividad. La efectividad de la matemática, tal como se entendió Eugene Wigner era un fenómeno de la física, no de la informática (ni de la economía).

Esto generó cierta inesperada reacción, que en ningún momento se planteó de forma abierta, en el nivel de gerenciamiento de los proyectos. Hubo algún tibio intento de sostener que determinados criterios debían permanecer privados porque eran demasiado delicados para exponerlos a la plebe: algo así como acabo de bajar del monte con las decisiones de dios escritas acá, miren. La posibilidad de no exponer motivos le da cierta ventaja al que asegura conocerlos, ya que siempre puede rechazar ideas con reglas ad hoc. Ser explícito es el primer paso para ser honesto. Unos pocos gritos después, seguimos adelante con el acuerdo de que los marcos de decisiones tienen que ser explícitos.

Los métodos de evaluación fueron un punto conflictivo. Hay determinados tipos de decisiones que necesariamente se definirán en el campo de las hipótesis, por así decirlo: son aquellas donde es imposible experimentar y los que pasa si son solo elucubraciones, ya sea por la naturaleza de la pregunta ( por ejemplo, como va a impactar en nuestra relación con el cliente un atraso de quince días?) o porque no tenemos la información adecuada .

Pero hay otro tipo de decisiones, particularmente decisiones importantes, donde el tiempo y la energía que se pierde discutiendo y conjeturando que va a pasar pueden ser invertidos en desarrollar una prueba. El post anterior contaba la historia del desarrollo de la guías para adoptar el método de decisión basado en la experimentación. El proceso de definir los métodos de evaluación (SP 1.4-1) es el mismo que el definir las soluciones alternativas (SP 1.3-1). En particular cuando la decisión sea lo suficientemente importante como para requerir experimentación, algunas alternativas quedarán descartadas por infalsables.

Para los métodos de evaluación basados en las etéreas elucubraciones, comenzamos por el final: el proceso de evaluación de alternativas tiene que tener una fecha de finalización o un máximo de esfuerzo invertido en él. La experiencia muestra que las primeras horas de las reuniones de revisión de pares y de análisis son las más productivas. No es que subestimemos la importancia y el poder del análisis abstracto, pero si nuestro proceso de análisis 'en abstracto' no tiene al menos algunos puntos de corrección por la experimentación, corremos el riesgo de desarrollar invertir esfuerzo en elucubraciones inútiles.

El ser humano no será demasiado racional, pero está enamorado de la coherencia. Nos resulta más fácil ponernos a defender la alternativa elegida con uñas y dientes que aceptar un error, porque así podemos percibirnos a nosotros mismos como personas coherentes, y porque, además, defendiendo nuestra elección, nos convencemos de que hemos elegido bien. Por esto, había que decidir que el jueguito dialéctico en alguna parte debía cortarse.

En este punto, alguien dijo la palabra mágica: brainstorming. Debo decir que no soy un gran fan del brainstorming. En particular, no compro la idea de que sin crítica se pueda arribar a una buena solución. No me imagino como se decantan por las mejores ideas si no las someten a un proceso de análisis crítico buscando los puntos débiles de las ideas propuestas. Por supuesto que la crítica tiene que ser fundamentada y no debe basarse en la autoridad ( el post sobre falacias argumentales, vale la pena o se soluciona con guglear un rato?) o en motivos emocionales, pero pensar que sin crítica vamos a obtener una buena solución es igual a pretender llevar a producción un sistema sin testing.

Definidas las guías para entrar al proceso, las de documentación de criterios de evaluación y del proceso, habiendo escrito un pequeño tutorial sobre como hacer experimentos, y como documentar los resultados (nada muy estructurado, apenas guías para que quede rastro del asunto) había algo que seguía haciendo ruido: nos parecía que había una tendencia general a no profundizar en las causas de algo al tomar una decisión.

No éramos los primeros en sentir eso, ya alguien había determinado que con cinco 'por qué' estábamos cerca de la causa última. Me mantengo escéptico sobre la pertinencia de este número, pero rescato el hecho de que anima a ir más allá al analizar algo y no quedarse con la primera explicación que, normalmente, suele ser incompleta. Por lo que pese a mi escepticismo (o gracias a él) la regla quedó en cinco por qués, o una explicación de por qué hay menos. El tiempo dirá como nos va con esta regla.

La tendencia a no profundizar lo suficiente en las causas se aprecia cabalmente cuando entramos en esa hermosa fase del ciclo de vida llamada 'mantenimiento': un bug corregido produce otros tres que a su vez producen otros más y así. Afortunadamente (porque no se debe sino a la fortuna de vivir en un universo con reglas que, al fin y al cabo, permiten la vida) en algún punto se estabiliza y cada patch nuevo no genera otros tres bugs, y entramos en régimen de uno a uno, o casi. Un régimen de mierda (aunque régimen al fin) provocado porque estamos solucionando síntomas y no causas.

Que como y cuando se solucionan las causas últimas? Bueno, llegado cierto momento, de ninguna manera, nunca. Pero aún cuando no tengan solución, siempre es mejor saber cuales son. Al menos, para no intentar resolver lo irresoluble.

Se lo digo yo, que de esto se mucho

2008-10-14T13:08:00.000-07:00

Esto sucedió unos 12 años atrás. Mi primer trabajo, aburrido, en un ambiente de un nivel pobre (me doy cuenta años después), pero que en ese momento viví como desafiante y lleno de oportunidades: bienaventurados somos quienes hemos recibido el enorme don del optimismo medio pelotudo.

Yo trabajaba en esos departamentos de soporte técnico que tienen las empresas que no son de sistemas, que por alguna razón llaman 'Gerencia de Desarrollo'. Es un poco buscapleitos, pero las empresas que no son de sistemas, no suelen tener departamentos de desarrollo, tienen departamentos de soporte de aplicaciones: corrigen alguna que otra nimiedad, implementan cuatro o cinco requerimientos nuevos al mes y atienden al usuario para cocinar datos con SQL ad hoc. Y atienden al usuario y cocinan datos, y así.

Por supuesto, mi llegada a esa empresa fue a través de una consultora, que a la muerte y al body shopping no le escapa nadie. Y ahí estaba yo, arreglando algunos bugs de un sistema pesimamente hecho (en C mal escrito, y con sintaxis de C++, para empeorar la cosa), fijándome por qué algunas transacciones se habían perdido, aceptando como un hecho que era normal que un sistema anduviera tan lento y tan mal, en definitiva, dándole manija al engendro ese para mantenerlo, no digamos andando, pero al menos con los procesos corriendo.

De paso, estaba conociendo como era el fascinante mundo empresarial. Una de las primeras cosas que aprendí era que había jefes. Eso lo intuía, porque si algo le queda claro a uno desde que tiene uso de razón es que hay estructuras jerárquicas. Además de los jefes, aparecieron ante mi otro tipo de personajes, estos inesperados: los gurúes, o los expertos. Estos eran gente grande (todos eran más grandes que yo en aquella época), normalmente de trato distante o, al menos, displicente.

Cuando se mencionaba a un gurú, su nombre se acompañaba de una fórmula, muy a la manera que los musulmanes usan para acompañar el nombre del profeta, la paz esté con él. Solo que en este caso la fórmula era "sabe mucho". Así se decía, por ejemplo, que "H. sabe mucho". Obviamente, no se los cuestionaba, ni siquiera se ponía a prueba lo que decían, hablaban ex cathedra.

Así, a mí me quedaba claro que tenía que seguir la corriente. No digo que haya creído honestamente en los gurúes (si bien no había formalizado para ese entonces mi postura filosófica, siempre la tuve medio pre-wired en mi cerebro) pero al menos no me sentía con derecho a cuestionar su trabajo o a hacer pruebas para ver si lo que decían era cierto. Podría decir que aceptaba su reinado, pero en el fondo la situación me parecía injusta, no sabía por qué. Diría hoy que en mi relación con ellos, era víctima de la disonancia cognitiva.

Un día, en particular, estaba enfrascado tratando de debugear un hermoso SIGSEV que el monstruo que me había tocado en suerte producía con puntualidad alemana cada cuarenta y cinco minutos. En el escritorio de al lado se sentaba C., un programador COBOL, que, ese día, estaba al borde del llanto porque un programa COBOL no compilaba. C. era un Programador Senior (tendría en ese entonces unos treinticinco años). Yo nunca vi COBOL más que en la facultad (la facultad no sirve para nada, título de otro post), por lo que me considero un tipo razonablemente afortunado, pero para dar la imagen de empleado del mes dije "C., te puedo dar una mano?". C. me miró incrédulo (le costaba entender como lo podría ayudar alguien con tan poca experiencia), y me dijo que sí, que claro, pero que el problema era demasiado complejo: no sabía si el COBOL estaba mal instalado en ese equipo porque ese programa no compilaba, y ese programa lo había escrito H. que sabe mucho y por lo tanto el programa no podía, por definición, estar mal escrito.

Asomé la cabeza y vi que había dos maneras de solucionar el problema: la primera era con un conocimiento acabado de la plataforma de COBOL (creo que era MicroFocus), y la segunda era leyendo el mensaje de error que daba el compilador informando que el problema era que el PATH de los archivos COPY (algo así como los headers del lenguaje C,creo recordar) tenía caracteres inválidos (la barra invertida en lugar de la estándar, o al revés). Cambiando la barra estándar por la invertida (o al revés) el programa anduvo.

C. no era un disminuído mental. Simplemente, no se atrevía a cuestionar la autoridad, estaba siendo víctima de la falacia del principio de autoridad, aún en un hecho tan nimio. No es un problema exclusivo de C., sino que todos tendemos a creer sin cuestionar en lo que dicen aquellos que, merecida o inmerecidamente, han ganado prestigio del entorno donde se desenvuelven.

No cuestionar la autoridad es, para Tom Kyte, una de las peores prácticas. No puedo menos que acordar con ello: todo concepto debe poder se puesto a prueba, no porque no existan expertos, sino porque, además de que hay menos expertos que gente que asegura serlo, todos, hasta los más grandes pueden cometer errores. Por otro lado, las cosas cambian: un concepto que era cierto con la tecnología de hace diez años, no es cierto ahora. Y además, si me permite la herejía, es posible que hasta los expertos se equivoquen.

Y si la pregunta es "vos quien sos para pontificar así desde tu blog? por qué deberíamos creer que vos sí sabés?", la respuesta es clara: suponiendo que esto lo lea alguien, no tienen por qué creer que yo soy un experto en nada.

Aislacionismo y Desarrollo

2008-10-09T12:54:00.000-07:00

Durante mucho tiempo el mundo académico ha tenido que lidiar con un hecho innegable que parecía sustentar algunas interpretaciones de nuestra sociedad que definitivamente repugnan. Aún así, este hecho es indiscutible: a lo largo de la historia, algunas culturas han sido muchísimo más exitosas que otras para dar respuesta a los deseos y necesidades que nosotros los humanos arrastramos por la vida, a cuya exagerada respuesta llamamos confort y que consiste, basicamente, en tener una gran cantidad de energía a nuestra disposición.

De forma inevitable, las explicaciones que se han propuesto se han derramado hacia la política. Primero, y aún no del todo superado, se propuso el racismo: las culturas que mejor responden a nuestras necesidades básicas son las que están conformadas por individuos intrinsecamente superiores. Como respuesta a semejante despropósito, se intentó negar el punto de partida: se argumentó que, en realidad, las necesidades básicas humanas no existían y que dependían de cada cultura. Así, cada cultura daría respuesta a sus propias necesidades y no habría posibilidad de decir que los humanos vivimos más confortablemente en una cultura que en otra.

De todas maneras había un problema: se estaba ante un hecho cuya existencia parecía estar más allá de cualquier duda razonable, una explicación repugnante del mismo y un intento de refutación algo débil (en definitiva, tan débil como el racismo, pero de debilidad más obvia, digamoslo así) que para colmo se empecinaba en negar un hecho evidente. En algún momento, alguien (en realidad, no se si la idea la propuso él o solo escribió un libro contándola) vino con una explicación : el grado de tecnificación de una cultura depende de su cercanía e intercambio con otras, con el fin de aprovechar las mejores ideas del entorno (el grado de tecnificación determina el nivel de confort). Por eso, observamos las culturas más avanzadas en Europa: una alta densidad poblacional relativa al resto del planeta en casi todas las épocas, conjugada con el hecho de que Europa corre de Este a Oeste, por lo que los climas y geografías parecidos facilitaban la adaptación de las innovaciones del vecino. En América, en cambio, el cambio en latitud hacía que, por ejemplo, los animales de carga domesticados por los Incas no pudieran ser utilizados por los Aztecas, con lo cual la 'evolución de las ideas' se hizo más difícil.

Algo parecido pasa en las organizaciones. Me comentaba un amigo que los gerentes y líderes de su cliente estrella no sabían que era una wiki, que era del.icio.us, no leían blogs y usaban internet para leer el diario o usar el home banking (o cosas inconfesables). Gerentes y líderes de IT, para más señas.

Se me ocurre que vale una analogía con la historia de la tecnificación y desarrollo de las culturas. Tu organización, por más grande que sea, se ha encontrado con un número pequeño de problemas y utiliza una cantidad de herramientas y técnicas limitadas, y su capacidad inventiva se limita a la capacidad inventiva de la gente que la integra. Si ese es tu único marco de referencia, te podés estar perdiendo el nacimiento de la metalurgia allá afuera.

Así como los highlands escoceses, dado su aislamiento geográfico, no pudieron construir su cultura sobre los adelantos tecnológicos de sus vecinos, estos tipos se encuentran con que no pueden reponer el conocimiento de la gente que se les va, tienen que volver a inventarlo. También encuentran terriblemente difícil resolver problemas que ya están bastante resueltos por ahí.

Más aún: compartir el conocimiento por fuera de tu organización es la única manera de asegurar que cierto conocimiento dentro de tu organización no se pierda. De nuevo la metáfora de Diamond: los habitantes de Tasmania tenían una cultura muy primitiva. No sabían hacer fuego, por ejemplo. Y sin embargo, cuando los aborígenes de Australia migraron hacia Tasmania, ya tenían un adelanto tecnológico mayor que el que los europeos encontraron en los habitantes de Tasmania. Por algún motivo (un liderazgo antitecnológico, muerte de los expertos por alguna causa rápida) perdieron parte de su conocimiento. Por supuesto, no es la única cultura que en la historia de la humanidad ha perdido parte de su bagaje de conocimientos, pero su aislamiento les impidió recuperar sus conocimientos simplemente imitando a sus vecinos.

En nuestra actividad no tenemos jefes luditas (bueno, no estoy seguro, pero asumamos que no) ni las plagas matan a nuestros sabios, pero creo que se puede aprender algo de la evolución de las culturas: tal vez valga la pena usar internet para algo más que leer el diario o pagar el teléfono, sobre todo si uno tiene alguna responsabilidad de gestión en una organización de IT. Y abrir a la comunidad lo que uno cree que aprendió podría servir, entre otras cosas, para que el conocimiento esté ahí después de un período oscurantista.

Pero aún tengo más: no termina de cerrarme la idea de que ir a escuchar a un gurú hablarle a un auditorio embelezado sea algo así como compartir el conocimiento. La construcción de conocimiento necesita, sin excepción, de la crítica. El conocimiento se modela a través del escrutinio de una comunidad interesada no en destruir al autor, sino en buscar las fallas del concepto propuesto y, en particular, en que punto ese concepto propuesto es incongruente con lo que se observa y con el conocimiento bien establecido, por lo que si todos estamos de acuerdo, me permito proponer, es que no hay ninguna idea que valga la pena.

Un apretón de manos

2008-09-22T10:11:00.000-07:00

En el mercado de competencia perfecta los compradores tienden a aumentar las cantidades compradas de un producto conforme su precio baja y a bajarlas cuando sube, mientras que los vendedores se comportan en forma inversa: aumentan su oferta cuando el precio sube y la retraen cuando éste baja. Así el mercado va encontrando su punto de equilibrio, que es el precio donde los vendedores ofrecen la cantidad de bienes que los compradores demandan. Este mecanismo fue descrito por Adam Smith, quien habló de la increíble capacidad de autorregularse de los mercados, como si estuviesen guiados por una mano invisible.

Sostienen los economistas neoclásicos que el mercado es la forma más eficiente de asignar recursos y que los problemas que ocurren en el mercado se deben precisamente a los intentos gubernamentales de regularlos (y no a la ausencia de regulaciones). Yo encuentro la primera parte de la afirmación más fácil de sostener que la segunda, sobre todo con las noticias de estos días. Los neoclásicos levantan su dedo índice y apuntan al cielo invocando a dios como testigo y nos recuerdan que ellos hablan de los verdaderos escoceses, (sigo teniendo pendiente el post sobre falacias argumentales) pero no es este el tema que quiero abordar, así que volvamos al hilo.

La mejor crítica que se le puede hacer a la idea del mercado de competencia perfecta es que no existe la información perfecta, que los bienes y servicios sí son distinguibles unos y otros y que hay sesgos psicológicos que hacen que los humanos prefiramos algunas cosas sobre otras (sin perjuicio de que las grandes sumas de capital necesario para entrar a proveer determinados bienes o servicios hacen que haya pocos proveedores para muchos compradores). La divergencia entre el mercado real y el mercado de competencia perfecta es, en mi opinión, particularmente notable en el mercado de trabajo.

El mercado de trabajo es ese donde empresas y trabajadores confluimos. Según la idea del mercado de competencia perfecta, cuando la demanda de bienes y servicios baja, las empresas demandan menos trabajadores, lo que haría caer al precio del trabajo (salario), manteniendo el nivel de ocupación. Como eso no ocurre en la realidad y existe ese temita que la teoría clásica no explica muy bien llamado desempleo, la culpa, para nuestros simpáticos amigos amantes de los verdaderos escoceses es de los sindicatos y regulaciones que no dejan que el salario (nominal) caiga, y entonces cae el nivel de empleo.

El mercado de trabajo pudo haberse ajustado a un modelo de mercado regulado por la mano invisible unos cuantos años atrás, antes de la especialización y del enorme peso del conocimiento en la productividad de los empleados. Puedo encontrar muchas diferencias entre el modelo y la realidad, particularmente en aquellas actividades donde el talento (o al menos el conocimiento y la especialización) de las personas es un valor clave para la empresa (el software, por ejemplo).

El empleador invierte tiempo y dinero en el empleado. Lo forma en la manera de hacer las cosas que la empresa ha ido adoptando, apoya su crecimiento profesional, se beneficia de un trabajador cada vez más calificado. El empleado a su vez, también invierte mucho en la empresa (yo diría que más que la empresa en él, no puedo ser objetivo): invierte su renuncia a otras posibilidades de ganarse la vida, invierte tiempo valioso de su vida, invierte sus conocimientos adquiridos con mucho esfuerzo. La ruptura de la relación laboral perjudica a ambos, particularmente si la relación no es reciente (por supuesto, el empleado es la parte más débil y es lógico que esté protegido por la ley).

Así, es probable que la dirección de la empresa se resista hasta último momento a desprenderse de los talentos, de esas personas cuyo conocimiento y habilidad constituyen un activo importante. Como ejemplo, podemos pensar en aquella gran crisis que vivimos por estas pampas hace no mucho: las empresas perdieron más facturación (y margen) que nómina. Esto ocurre, en parte, porque en la empresa existe la expectativa de que las cosas se recuperen y, en tal caso, el conocimiento no va a ser facilmente reemplazable.

Hay más en la ecuación que diferencia al mercado de trabajo del modelo regulado por la mano invisible: la asimetría de la información. Si quiero ir a trabajar a otra empresa, ellos no conocen de la lista de logros que he conseguido en la empresa donde estoy actualmente: los puedo contar yo, pero entiendo no ser una fuente demasiado confiable y objetiva sobre mí mismo. Por eso, salvo casos excepcionales, no me van a poder pagar en función de mi experiencia para un puesto similar. Ahora, yo tampoco los conozco a ellos: no se si me adaptaré a su forma de hacer las cosas, no se si mi futuro jefe tendrá los mismos valores que yo. Ambos ignoramos cosas que el otro sabe. Y por eso, ambos queremos cubrirnos con un margen en la remuneración, solo que, obviamente, en sentido opuesto.

Arthur Okun definió esto como un apretón de manos entre empresa y empleado (no encontré ningún artículo que describa rapidamente la tesis del libro).

Como decíamos antes, el apretón de manos, por su propia naturaleza, no deja a las empresas en una posición de absoluta ventaja. Un empleado que ha crecido en una empresa, del que sus superiores conocen sus fortalezas y debilidades, que ha formado su perfil profesional en esa empresa no puede ser reemplazado por el mismo costo. Si este se fuera, la empresa se vería en la obligación de elegir entre pagar más para cubrir la misma posición o pagar lo mismo pero afrontar la incertidumbre sobre el desempeño de quien viene a cubrir la vacante (por ejemplo, por una promoción interna).

Y aquí viene algo así como el reclamo sindical: muchas veces, los empleados recibimos como respuesta tácita o explícita de nuestros empleadores la frase "estás pagado acorde al mercado". Ahá. No me digas. Me estás queriendo decir que yo no conseguiría facilmente un salario superior al que gano por el trabajo que hago en otra empresa o que vos me reemplazarías al mismo costo?. Porque una cosa puede ser cierta, pero la otra no lo es.

Recordar que nuestra relación es un apretón de manos, tanto cuando uno está en posición de defender los intereses de la empresa, como cuando uno está defendiendo los suyos propios, podría contribuir a mejorar enormemente el nivel de satisfacción de los empleados con las empresas, y de las empresas con los empleados.

En el medio del diablo inventó el body shopping. Y sobre eso, no voy a repetir lo que tan bien dice don M. aquí sobre el hijo bastardo de la necesidad de dibujar ciertos indicadores para parecer más eficiente. Dije que no iba a decir nada. Y no pude cumplirlo.

Engañemos a la realidad

2008-09-18T12:39:00.000-07:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Diseñando experimentos o experimentando diseños

2008-09-12T20:38:00.000-07:00

Hubo un tiempo que fue hermoso, y fui libre de verdad. En ese tiempo era un técnico, me perdía entre arquitecturas y optimizaciones, y las fechas, rentabilidades, calendarios, ofertas no eran mi problema. Mi responsabilidad se limitaba a aquellas cosas que hacía yo directamente. Estaba en la gloria. Además, como solo mi trabajo era mi responsabilidad, podía hacerme el vivo.

Magnificadas y embellecidas por la memoria, de esa época tengo recuerdos como el que sigue.

Una programadora del equipo se acercó a D., intuyendo lo peor. No se por qué se acercó a D. , siendo que yo era la interfaz más amable de ambos y nos sentábamos uno al lado del otro (yo era algo así como el arquitecto de aplicaciones y D. el de base de datos). Ella, que sabía lo que seguía, le dijo a D.: "esta query anda lenta" y se dispuso a aceptar con resignación su destino. D. ni siquiera levantó la cabeza del monitor y dijo "ahá. y que querés hacer..." (D. siempre citaba a Tom Kyte diciendo "no optimices queries, comprendé la pregunta").

Hasta aquí, la morocha (dije que la programadora era morocha?. Bueno, era morocha y de ojos verdes) tenía una oportunidad. No es que D. fuera muy amable, tampoco es que la curvilinea figura de esta chica lo conmoviera, sino que él siempre intentó ser justo. Ella no se dio cuenta que tuvo una oportunidad de ser rediminda y dijo "no, es que quería ver si desde la base podíamos hacer algo para que ande más rápido". Era exactamenet lo que D. estaba esperando para reconfirmar que toda oportunidad otorgada es una pérdida de tiempo: "algo así como poner el parámetro turbo=true? no, todavía no existe. Te aviso cualquier cosa".

Se puede decir que D. era (es) un tipo áspero. Que no hay necesidad de andar presumiendo de lo que uno sabe, porque uno en algún momento uno tampoco supo. Pero creo que en esta oportunidad el problema no era con la ignorancia, sino con un concepto problemático: la performance no importa, la performance se agrega después, es como la cobertura de un helado, y además es algo que depende del DBA.

A D. lo irritaba esa postura. A mí también. El origen de mi molestia tiene que ver con que considero que no se puede evitar el pensar la arquitectura al principio del proceso de desarrollo del software (lo que no implica, claro, que uno no tenga que pensarla durante todo el proceso), no importa cuan ágil sea uno (de todas formas, el paso de planear la arquitectura se evita más por desordenado que por ágil, se reconoce desde la comunidad ágil que la fase de architecture envisioning es necesaria), particularmente si uno no quiere encontrarse al final del proyecto con que algo anda más lento de lo esperado, o algo peor.

Se podría argumentar que ese no es un problema hoy en día: hay arquitectos, fases para definir la arquitectura, sectores de arquitectura, libros sobre arquitectura y toda una parafernalia sobre el asunto. Me permito pensar que todo eso, o bien es insuficiente, o bien está mal dirigido.

Volvamos al principio, que es la arquitectura?. Yo tengo una definición de arquitectura: “la arquitectura de un sistema es el conjunto de decisiones de diseño que tienen un impacto profundo en la calidad del mismo” (en realidad, como todos las cosas que valen la pena, ya alguien la pensó antes).

Por eso, creo que la fase de pensar la arquitectura, de decidir las características más importantes del sistema antes de comenzar la construcción y no esperar que las decisiones tomadas por un grupo de desarrolladores sobre la marcha sean acertadas, es ineludible. De todas maneras, creo que una vez más conviene bajar a detalle y preguntarse que significa obtener una visión de la arquitectura. No creo que unos modelos en papel alcancen para tomar decisiones importantes, particularmente cuando uno incorpora componentes nuevos (no recuerdo ningún proyecto en los últimos años en los que no haya tenido por lo menos un componente nuevo). La solución viene dada por construir diseños experimentales que sometan a la arquitectura propuesta a condiciones extrapolables a las que soportará una vez implementada.

Las características que normalmente deseo observar al someter a una arquitectura a un experimento son:

El comportamiento bajo alta carga.
La posibilidad hacer andar en forma aislada los componentes, como forma de poder detectar y corregir problemas una vez que esté el sistema implementado.
El comportamiento ante situaciones límite, como caídas de equipos, operaciones maliciosas, errores en otros componentes.
La facilidad de implementar cambios en la arquitectura (reemplazar un componente por otro).
Cierta seguridad sobre la estabilidad de los componentes. Si bien no tengo demasiado cariño por la costumbre de gritar ‘hay un bug en Oracle’ ante el primer error que uno cometió en una query, me he encontrado con algunos productos open source con algún que otro error (un memory leak, por ejemplo). Y me he encontrado con que MS se pasa algunos estándares por el forro, y agrega algunas condiciones a las del estándar....
Y el más importante, nuestras suposiciones sobre el funcionamiento de lo que vamos a usar son razonables? O sea, podemos estar seguros que, al menos en lo importante, nuestro diseño no va en contra de algunas limitaciones de la tecnología?

Bien, el problema es que esto es mucho más fácil de enunciar que de hacer. Diseñar un experimento significativo y a la vez sencillo es una habilidad que requiere conocimiento, práctica, y hasta diría que talento. Si es difícil hacerlo, escribir unas guías sobre como hacerlo es aún más difícil, pero concluímos que hacer el esfuerzo (más adelante explico el por qué, además de porque consideramos que aporta valor) de explicitar algunas guías para definir experimentos valía la pena. Acá va un resumen de los pasos de la guía:

Identificar las interfaces relevantes: pueden ser algunas pantallas, mecanismos de IPCs e integración (colas de mensajes, web services)
De las pantallas identificadas, abstraer la presentación y pensar unicamente la interfaz de la operación
Desplegar el software de base. Acá me refiero a desplegar todo el software de base, no un poco, particularmente si uno no lo conoce. Me refiero a base de datos, appl. server, broker de mensajes, todo.
Implementar mocks de cada interfaz relevada. El mock, de acuerdo a cada caso, puede ser una clase que simplemente no haga nada y tenga un sleep o similar para simular el delay de procesamiento o una clase que haga algunas operaciones contra el soft de base, sin mayor lógica, simplemente para obtener tiempos reales de operaciones en el soft de base
Conseguir un simulador de carga (o hacer al menos un par de scripts en ant, nant o shell) que tire transacciones.

A partir de ahí, ir variando las condiciones y ver que sucede (algunas ideas):

Ejecutar lo construido en (5) y verificar límite de capacidad de procesamiento (ese momento donde las colas no entran en régimen: al margen, la utilidad de los modelos de colas para el análisis de performance, tema para otro post)
Bajar intempestivamente un componente y ver cuan fácil es determinar el problema
Determinar que posibilidad hay de ejecutar aisladamente un componente construido sin el software de base (obviamente, con máquina virtual y sistema operativo, unicamente)
Medir el consumo de memoria de los componentes, particularmente de los nuevos (si pusimos un nuevo framework, medir el consumo de memoria en la máquina virtual, por ejemplo)

Un experimento (o prueba de concepto, o como se desee llamarlo) es un entorno controlado donde podemos generar variaciones planificadas y observar los resultados. Es sencillo de enunciar, pero diseñar un experimento razonablemente significativo es algo que requiere práctica, conocimiento del dominio y no se si talento natural ( sí, se que todo parece indicar que no somos una tabla rasa, pero tampoco es que don Pinker se haya impuesto por tanto).

Aún así, y dado que teníamos que cumplir, pensamos que sería útil hacer el esfuerzo de escribir un manual, o al menos unas guías, que ayuden a quien tenga que hacerlo a diseñar un experimento. Al fin y al cabo, que sea difícil de aprender, no significa que no valga la pena de ser enseñado, no?

Por qué todo esto?. Basicamente porque existe en CMMI L3 un área de proceso llamada ‘Decision Analysis and Resolution’. Como además de la certificación siempre tuvimos como norte que el proceso sirva, además, para que mejoremos la calidad de nuestros productos, nos atrevimos a perder tiempo pensando en el proceso de desarrollo además de la estrategia para el SCAMPI.

En la próxima parte de este post veremos como encaja esto en la process area de 'Decision Analysis and Resolution'.

La pregunta más estúpida

2008-09-10T08:14:00.000-07:00

El Large Hadron Collider es una magnífica oportunidad para que un montón de gente muestre el grado de su imbecilidad. Me siento en la obligación de aclarar una obviedad: imbecilidad no es ignorancia. Es perfectamente normal, lógico, entendible, no entender qué se está buscando con el LHC ( recomiendo seguir el link si se desea una explicación sencilla y rápida del LHC) porque la física de partículas es realmente compleja (y aunque Mario Bunge se enoje, yo diría que es terriblemente antiintuitiva). Lo que constituye imbecilidad es decir, como una conductora de televisión que esta mañana he tenido la mala suerte de escuchar (solo por querer saber la temperatura exterior antes de salir de casa), que es contradictorio que se llame la máquina de dios cuando están tratando de demostrar que dios no existe.

Sin llegar a las cotas increibles de estupidez que ha demostrado esta mujer, se puede plantear una pregunta estúpida, la pregunta más estúpida: para que sirve todo eso?. Esta pregunta no es estúpida cuando es sincera y el post de Dirección de Proyectos linkeado más arriba la responde. Esta pregunta es estúpida cuando va acompañada de un dejo de crítica porque "con todos los problemas acuciantes que tenemos que resolver, gastar tanto dinero en eso... que terrible".

No voy a negar que tenemos problemas acuciantes que resolver, pero es ridículo pretender saber con anticipación la utilidad de la investigación básica. Es incluso probable que no la tenga, pero solo podremos encontrar conocimiento útil si buscamos conocimiento, a secas. Me sorprende lo poco extendido que está este concepto, incluso entre gente que aceptaría que un negocio con una rentabilidad garantizada a priori es una quimera (o una estafa). Bueno, la investigación es un negocio sin rentabilidad garantizada a priori, pero con una historia de éxitos impresionantes.

Me gusta la anecdota que cuenta Steven Weinberg en "El sueño de una teoría final": la reina de Inglaterra, luego de recorrer el laboratorio de Michael Faraday y asombrarse con unos juguetitos electricos, le preguntó a éste: y todo esto para qué sive?. Faraday le dio la mejor respuesta que he escuchado a esta pregunta: y para que sirve un recién nacido, majestad

Sin llegar a lidiar con cosas de la complejidad del CERN, me gusta trabajar en empresas que entienden que la investigación es, por un lado necesaria si se pretende mejorar el estado actual de las cosas, y por el otro que no se puede saber a priori para que servirá el conocimiento obtenido.

Para qué sirve el libro que estás leyendo?. No deberías leer libros en el horario de trabajo, tenemos demasiado que resolver antes de empezar a investigar.

El valor ganado

2008-09-02T10:18:00.000-07:00

Scott Ambler, entre otros, critica el uso de Earned Value como métrica para los proyectos de desarrollo, y como siempre, con muy buenas razones:

Se tiende a asumir que toda tarea realizada es valor ganado, así, por ejemplo, llegamos a que ganar el 90% del valor nos cuesta el 90% del esfuerzo y el último 10% de valor otro 90% ( me encantan esos proyectos donde siempre estamos finalizando.)
Es difícil usar el EV para el software, ya que el nivel de interdependencia de los componentes es alto.

Repasando el earned value, la forma de calcularlo es asignarle un valor a cada tarea, definir una política de suma (es decir, si puedo sumar un 50% de la tarea o solo sumo tareas completas), y luego, con el avance, recolectar lo terminado y hacer una suma de los valores de cada tarea terminada.

Yo siempre pensé que me gustaba el Earned Value, de hecho, iba a escribir un post para defenderlo. Lo que ocurre es que estuve años diciéndole Earned Value a otra cosa. Suele pasar, sucede lo mismo cuando digo que soy liberal y me saludan como compañeros de ideología cada personaje... (no, no voy a hablar de política, pero soy liberal, humanista, y ... bueno, si les interesan sigan los links al think tank de Paul Kurtz ).

Volviendo, mi earned value se basa en lo siguiente:

Primero, no toda tarea aporta valor. Hay tareas necesarias para laburar pero que, luego de terminarlas, no tengo algo de software que mostrar. Sería delirante decir que tengo dos mil pesos de earned value porque terminé de conectar mi entorno de desarrollo. Después de tener mi entorno de desarrollo up & running, mi earned value es cero. Todavía no gané ningún valor.
Yo entrego productos, no tareas cumplidas. Por lo tanto, el earned value se incrementa cuando termino una parte del producto, no cuando termino una tarea (y por cierto, terminado es terminado, no es terminado pero me falta probarlo)
Lo que me dice cuan cerca estoy del objetivo es la distancia que me separa del mismo, no cuanto recorrí para llegar a él. Mi objetivo no es estático, aún cuando trabaje con BRUF, ya que manejo el cambio. Entonces, mi EV no lo voy a comparar con la estimación original, sino con la estimación actual de acuerdo a la configuración actual del producto que debo entregar
El software sí puede dividirse en piezas: si tengo una lista de componentes a realizar, un diseño de alto nivel y una lista de funcionalidades, es que cada una de esas tiene alguna entidad propia. Y como tal, puedo decir que cada una de ellas está implementada o no está.

Claramente, en un proyecto ágil 'puro', donde no se cierren los requerimientos al principio, el earned value no tiene sentido. Pero como argumenté en otro post, me veo obligado a trabajar con lo que Ambler llama BRUF.

Y así tengo un gráfico con una linea que representa el valor actual del producto a construir (es decir, la sumatoria del valor de todos los componentes que representan la configuración actual del producto a construir) y una linea que representa el valor ganado (la valorización de aquellos componentes terminados y útiles para la configuración actual del software). Esto implica, claro, que el valor ganado puede bajar y que el objetivo no es estático. Acá hay un ejemplo del gráfico en cuestión:

Por supuesto, hay más datos que tal vez valgan la pena volcar en el gráfico (la valorización de las tareas que no aportan valor directamente al producto, por ejemplo), pero por ahora lo uso así.

La forma de medir el avance de un proyecto siempre es un tema complicado. Lo que subyace, me parece, es uno de los dos grandes problemas que también subyace al tema de las estimaciones: no tenemos una buena forma de medir el tamaño del producto de nuestro trabajo (como nota al margen, no creo que lo ignoremos por tontos, sino por recién llegados).

Y esto que tiene que ver con el earned value?. Bueno, para mí es el earned value: es el valor que logré ganar. Ah... que la definición era otra?. Bueno, podría ser. Ya comenté que soy liberal?

Escolástica y Positivismo

2008-08-26T13:18:00.000-07:00

A veces me sorprendo a mí mismo pensando que la evolución, tal como ha sido descripta por el genial Charles Darwin (y ampliada o explicada a la luz de la genética por el neodarwinismo), explica todo. Es decir, explica el funcionamiento de nuestro cerebro, explica la tendencia a la xenofobia, nuestra irracionalidad, y además nuestras cosas buenas, como el amor a nuestras crías.

Incluso más, como propone Stanislav Lem en 'Invencible', creo posible ámbitos de evolución no biológica: el capitalismo de mercado sobrevivió porque es el sistema mejor adaptado a la forma de ser de nosotros los humanos ( lo que no quiere decir que nos tengamos que quedar con su forma actual ), las ideas sobreviven por su adecuación a nuestra idiosincracia, y así unas cuantas cosas. Bueno, también lo propuso, creo que después, Richard Dawkins con sus memes

El mismo fenómeno de evolución se da con el software. El software que detestamos, ese que legamos y que queremos tirar, ha estado sobreviviendo al medio durante mucho tiempo. Eso no quiere decir que sea perfecto, la evolución no encuentra la mejor solución: encuentra una solución que permita que el organismo viva. Y eso ha hecho, ha sobrevivido. Con sus problemas, claro: no sabemos si un determinado código anda de casualidad o no, no nos animamos a tocarlo, es poco claro, si se hubiese pensado de una para el uso actual sería más claro, la tecnología es vieja, y unas cuantas cosas más. Pero aquí esta, y eso es una señal de que tiene algo de conocimiento valioso.

Por eso me irrito cuando se empieza un proyecto de reingeniería y todo el mundo está convencido que el nuevo software será mejor que el anterior, simplemente porque el anterior era una bosta. El anterior vivió muchos años, sobrevivió y se adaptó: el que no hicimos, todavía no demostró tanto mérito y no va ser fácil prepararlo para que lo haga, o, al menos, no lo haremos sin esfuerzo simplemente porque somos más vivos que los anteriores.

Por supuesto que parte de nuestros problemas para hacer algo bueno tiene que ver con las imperfecciones adaptativas del sistema anterior (que si no las tuviera, no lo estaríamos cambiando): no hay documentación, la tecnología es vieja y el código es poco claro, incluso subóptimo (a veces no es subóptimo, nos parece subóptimo porque lo evaluamos con poca información)

Y acá llegamos al punto donde quería llegar: la documentación. Estos sistemas legados no tienen documentación, o si la tienen, no podemos confiar en ella porque está desactualizada. Este es el estado general de las cosas, y creo que vale la pena preguntarse por qué con inexorable fatalidad la documentación falta o está desactualizada. Voy a hipotetizar algunos puntos:

La documentación se desactualiza porque no se percibe como útil. Y no se percibe como útil porque muchas veces no lo es: antes de documentar algo deberíamos preguntarnos si es más fácil leer la documentación que el código (he visto 'documentación' que ha sido el mismo programa hecho en pseudocódigo).
Aún cuando la documentación no esté desactualizada, siempre nos inunda la sospecha sobre su pertinencia al estado actual del sistema. Esto es, en parte, porque sabemos que la documentación tiende a desactualizarse, pero hay una causa subyacente ahí: cuando leemos documentación no tenemos más que el auxilio de la fe. Es decir, creemos que la documentación está actualizada porque alguien nos los aseguró, no porque podamos comprobarlo.

Diría que la misma presión del entorno que ha moldeado el sistema a su forma actual ha presionado para que la documentación se abandone. Bueno, y entonces qué? dejamos que el código se comente solo?. Yo creo que tenemos que adoptar una solución basada en criterios robados: es mejor almacenar experimentos que descripción de los resultados del experimento. Los físicos no lo pueden hacer: por ejemplo, el CERN no puede dejarnos jugar con su LHC un rato para ver lo que finalmente salga, pero nosotros tenemos una ventaja: podemos empaquetar el software junto con los experimentos que permitan ver si el mismo anda: test unitarios (como junit, nunit) y de regresión (como jmeter, selenium).

En mi opinión, los scripts de test son la única documentación que podremos utilizar sin temor a que esté desactualizada: el test se puede someter a prueba, se puede ejecutar, sirve para experimentar, mientras que la documentación se queda horriblemente corta al respecto. Incluso, me siento cómodo aplicando esta idea al desarrollo de requerimientos cuando lo que tenemos es un software que reconstruir: más que producir modelos en papel, preferiría producir scripts de test.

Lo anterior no es ni más ni menos que otro triunfo de la experimentación y el positivismo sobre la visión escolástica.

La importancia de la historia

2008-08-22T19:21:00.000-07:00

Amo la frase "Dejó de andar. Y nosotros no tocamos nada" porque ha hecho que casi todo el mundo acepte la necesidad de la práctica de gestión de la configuración, cuyos beneficios van más allá de dar respuesta a esta frase. Además, claro, es una de las áreas del nivel 2 de CMMI, así que la tenemos que cumplir. La tenemos que cumplir, no se discute: no importa para qué, acá no se discute, la duda es la jactancia de los intelectuales (*): si lo dice CMMI hay que hacerlo.

Perfecto, lo hacemos. Y vamos a la definición de CMMI, que como todos sabemos explica, en un lenguaje accesible el significado de algunos términos criollos . (van solo los objetivos específicos, las prácticas y subprácticas se encuentran muy fácil por ahí)

Se establecen las lineas bases (cuidado!!! no es el concepto de linea base de ITIL que es más o menos el que todos entendemos por linea base) de los productos identificados.
Los cambios a los productos bajo gestión de la configuración son seguidos y controlados
La integridad de las lineas base se establece y mantiene

Clarísimo, no?. Bueno, no para nosotros. Como siempre la pregunta ante esto es... "y que hacemos?". Después de un tiempo de discutir, van unos revolucionarios conceptos a los que llegamos:

Tener versionado de código no es hacer gestión de la configuración: además tenemos que identificar los hitos o releases usando el versionador de una forma coherente y homogenea. Por ejemplo, teníamos que poder decir "volvamos a la versión que entregamos el viernes pasado". Pan comido, un sencillo mecanismo de tags y branches y listo.
El código fuente en el versionador no es suficiente: he visto que hay una tendencia a no versionar los objetos de la base de datos. A veces, con suerte, llegamos a los stored procedures, pero no versionar ni tablas ni índices es lo habitual: después de todo no son código fuente, no?. Yo me atrevo a proponer una tesis subversiva: si no hay coherencia entre el código y los objetos de la base, existe cierta posibilidad de que la release sea fallida.
Tenemos que saber que incluía cada revisión: que bugs estaban resueltos, cuales no, que funcionalidad implementada, que errores conocidos que íbamos a resolver en cada revisión. Para esto, necesitábamos algo más que un versionador de código. Había que adoptar un issue tracker e integrarlo con el versionador. Primero a mano, incluso ingresando la relación con los branches y tags a mano en el campo de descripción, después si se puede, se automatizará. ( Esto da pie a hablar del mejor argumento para impedir cualquier mejora: Pedir la perfección. Si uno no quiere hacer nada, puede atacar cualquier cosa que le propongan por no ser perfecta. Será motivo para otro post)
Si algo había cambiado, teníamos que saber cuando había cambiado, ser capaces de elucidar las diferencias con la versión anterior y en lo posible, tener una noción de por qué había cambiado y el impacto. Esto estaba bien, no? Al fin y al cabo ya teníamos el versionador de código. Bueno, tampoco: esto incluye a los planes, descripciones técnicas y funcionales, algún que otro modelo (no soy un gran fan de modelizar todo y no me asusta la documentación de diseño desactualizada después de que el proyecto ha terminado, me inclino más por el modelado ágil, tema para otro post). Además de incorporar todo esto al versionador, usamos el issue tracker para conocer el momento, motivo e impacto de los cambios
Deberíamos ser capaces de sacar una foto completa de una release. Esto es, no solo lo necesario para desplegar cualquier release por la que hayamos pasado (esto es código, scripts, objetos de la base, dtd, etc, etc, etc) sino especificaciones, reportes de bugs, scripts de pruebas y demás. De nuevo, no era difícil si subíamos todo (no solo el código) a un gestor de versiones y nos apoyábamos en el issue tracker.

La idea de tener aunque una descripción de los motivos del cambio levantó algunas discusiones sobre si era agil escribir el por qué de cada cambio importante (no, no hay una definición de importante. Aún no hemos encontrado un buen sustituto para la inteligencia, y espero que no aparezca). Mi postura fue que sí (o que si no era ágil, igual lo teníamos que hacer), basado en el siguiente argumento: si no está escrito no se puede revisar y aprender de ello (**), y necesitamos aprender de nuestra experiencia. Lo ágil, desde mi punto de vista, es no escribir más de lo necesario ( y cuanto es lo necesario? bueno, ver definición de importante más arriba).

Por supuesto que la frase "Dejó de andar. Y nosotros no tocamos nada" es cierta a veces (los tablespaces se llenan, los campos númericos se muestran cortos de un día para otro, bugs latentes salen a flote cuando se pasa determinada cantidad de información). También, como decía antes, la gestión de la configuración no solo da respuesta a esta frase. Incluso, el orden temporal no es necesariamente indicio de causalidad: que dos cosas hayan pasado en secuencia es prueba insuficiente de que la primera hay causado la segunda (o sea, la falacia post hoc ergo propter hoc. Motivo para otro post: falacias argumentativas)

No me propongo argumentar que la gestión de la configuración haya sido una respuesta a la costumbre de reportar errores usando esta frase, pero sí decir que donde han sufrido estas cosas es más fácil hacer ver la importancia de la gestión de la configuración.

Lo que me queda claro es que se agradece que haya gestión de la configuración cuando "dejó de andar. Y nosotros no tocamos nada". Primero, porque como diría el gran Dr. House, "todos mienten" (a propósito o sin querer, todos mienten). Y después, porque si estamos en alguno de los extraños casos donde efectivamente, ellos no tocaron nada, sirve corroborar tan sospechosa frase en los registros de gestión de configuración y comenzar a buscar campos que quedan chicos, problemas de memoria latentes que surgieron cuando se incrementó el volumen de transacciones, funcionalidad que hasta ese momento no había sido usada, un diseño deficiente de sincronización de transacciones que por obra y gracia del espíruto santo no había llegado a verse envuelto en la condición que lo hizo dispararse.

Ahá, muy interesante, pero con todo esto que nos explicaste vamos a cumplir con CMMI?. Sí?. Bueno, entonces hacelo y comprá el software que necesites, pero buscá el más barato.

Me encanta sentir que he cautivado a mi audiencia.

(*) Frase que ha pronunciado el filósofo Aldo Rico durante una rebelión carapintada. Algunos aseguran que fue Ortega y Gasset ( tan filósofo éste como el antes mentado) el autor original del a frase.
(**) No me imagino a un científico diciendo "Lo que ocurre es que yo no escribo papers porque hago ciencia ágil. Mejor que se siente el revisor al lado mío y le voy contando las ideas" (sí, como dije, considero la ciencia como paradigma de éxito en cuestiones intelectuales)

Estimo que...

2008-08-19T14:43:00.001-07:00

Como parte de nuestro programa de mejora continua en el proceso de estimación, y dado que aún tenemos la hermosa sensación de desafío que produce el saber que existe una magnífica oportunidad de mejora en este tema (esta forma de decir 'quilombo a resolver' la aprendí en un curso de coaching), estuvimos pensando en que, si el proceso de estimación está tan verde, tal vez mereciera la pena invertir un par de horas en revisar los resultados.

Tuvimos que asumir que era (y es) nuestro punto más débil. Listo, agarramos la definición del proceso y le agregamos un paso más. Y salvado el hombre, hermanos!. Bueno, nada es tan simple: como hacíamos para que las revisiones tuvieran un mínimo de sentido crítico? (no es el sentido crítico una de las cosas que nos salgan naturalmente a los humanos, de hecho, la tendencia a buscar acuerdos es un sesgo cognitivo bien descripto. Motivo para otro post, o simplemenet podría recomendar un libro).

Entonces comenzamos a hacer un checklist de cuestiones a repasar cuando revisamos una estimación. El desafío y la oportunidad de mejora siguen ahí, de modo que la lista sigue abierta (como un recordatorio, esto lo aplicamos al método de estimación por descomposición). En estos momentos,la guía para el revisor se basa en un par de aspectos generales, que explico en los puntos siguientes.

Coherencia con los objetivos y requerimientos

La estimación debe mantener coherencia con los requerimientos no funcionales y los objetivos de rendimiento (*). Por incoherencia entendemos el incluir un objetivo o requerimiento y que las tareas para alcanzarlo o cumplirlo no tengan el foco (esto es, esfuerzo) necesario o directamente brillen por su ausencia.

Las formas más comunes de estas incoherencias son:

Mencionar en los objetivos de rendimiento que vamos a construir un producto (o un framework) a partir del proyecto, y las tareas de diseño no tienen mayor peso que de costumbre, o las tareas de documentación brillan por su ausencia.
Hablar de objetivos de performance del producto y no incluir tiempos para tareas de pruebas de carga, ni especialistas en el asunto.
Incluir cuestiones tecnicamente complicadas ( como por ejemplo, alta disponibilidad) y no estimar el esfuerzo adicional de diseño, y, fundamentalmente, prueba.

Por otra parte, el ciclo de vida seleccionado tiene incidencia en las estimaciones. El riesgo aquí es no estimar el esfuerzo de ciertos roles o actividades que el ciclo de vida que adoptamos incluye.

Identificación y estimación de tamaño de las tareas

Dijimos que adoptábamos un método de descomposición y no uno paramétrico como nuestro método principal porque no teníamos la suficiente madurez para un método paramétrico. Ahora, eso no implica que no podamos identificar algunos patrones de errores comunes en la identificación de tareas:

Las tareas o componentes identificados son lo suficientemente pequeños como para que su estimación sea posible?. Como regla general, establecimos que cualquier tarea o componente que insuma más de 150 horas es sospechoso de estar pobremente especificado y comprendido (otra regla general: no hay cosas que estén mal por definición, hay luces amarillas)
Se han identificado las oportunidades de reutilización?
Se distingue entre lo que se debe modificar, lo que se integra y se prueba en integración y lo que se construye desde cero?

Coherencia histórica

No tenemos una historia especialmente explotable, en un sistema de datamining que nos permita descubrir patrones de esfuerzo en proyectos pasados. Bueno, pero que no tengamos el non plus ultra de los repositorios no implica que no podamos ver como nos fue en el pasado ( en algún caso, junto con algún otro galeote hemos mirado un reporte en excel decidiendo por una descripción a que componente imputar las horas de un proyecto pasado... un trabajo apasionante cuando hay cientos de componentes y miles de entradas de cargas de horas ).

Y aquí la pregunta que terminamos haciendo: si para hacer un ABM tardaste miles de horas, por qué ahora suponés que lo vamos a hacer en veinte?. Resumiendo, este paso implica buscar componentes o tareas parecidos (al menos parecidos en una primera aproximación) en proyecto anteriores y justificar la diferencia si la hubiera. No es que siempre tengamos que tardar lo mismo, pero la diferencia debe tener una buena justificación.

Evaluación de la incidencia del entorno

Este paso, al igual que todos los otros, tiende a buscar incoherencias entre lo que ha escrito y especificado sobre proyecto y su circunstancia y lo que se supone que se hará en virtud de eso. Mencionar una característica del entorno, como por ejemplo un riesgo, y que no haya ninguna característica de la estimación o del plan de proyecto que responda a ésta es wishfull thinking, es creer en la utilidad de un conjuro. Por eso, lo que hacemos aquí es recorrer cada riesgo, cada característica del entorno (capacidad del equipo, motivación, estabilidad de los requerimientos), y preguntar y esto como influyó en la estimación? como hubieses estimado si esta hubiese sido diferente?

Pasos de la estimación

Por último, el aspecto formal, aunque debería haber sido el primero. Si el único repositorio de la estimación y sus motivos está en las conexiones neuronales de un iluminado, dificilmente podrá ser sometido a revisión. Entiendo que los genios tengan esa reticencia a la revisión, pero, queridos genios, entiendan que, nada personal, nosotros los mediocres, nos vemos forzados a actuar como si la regla fuera la mediocridad y no la genialidad, como si ustedes los genios fueran raras avis. No es que dudemos de vuestra genialidad. Y así hemos logrado estructurar al mundo: aún los premios nobeles escriben sus ideas para que los demás las puedan evaluar, juzgar, corregir, ampliar y si las encuentran útiles, usarlas de base para otras ideas. Incluso, para permitir que si los demás las encuentran terriblemente revolucionarias, les den el premio nobel.

Así que acá vamos con los pasos en cuestión:

Se han establecido, a grandes rasgos, los límites del alcance y los objetivos de rendimiento?
Se han indentificado los riesgos?
Se han identificado las tareas y componentes siguiendo la taxonomía que se usa habitualmente o si se la ha ampliado hubo una buena razón?

Resumiendo

Cuando uno tiene un proceso cuyos resultados no han destacado por su fiabilidad en el pasado (esos papers que hablan de cuanto se van de presupuesto y calendario tantos proyectos de software no nos hablan en tercera persona, deberíamos asumirlo ...), y no sabe muy bien como mejorarlo, lo mejor es aumentar las actividades de revisión y rezar porque la coherencia interna de un producto tenga alguna relación con su pertinencia y ajuste a la realidad.

Gran parte de lo que hicimos lo tomamos de un checklist del SEI para revisar estimaciones, como cabe esperar, bastante más formal y estructurado que el nuestro.

(*) Objetivos de rendimiento le llamamos en este barco de esclavos a aquello que se espera que nos aporte el proyecto además, claro, de su rentabilidad (la base para algún producto, conocimiento, entrar en una cuenta)

El punto singular

2008-08-11T08:18:00.000-07:00

Recientemente el IEEE ha publicado un informe sobre la singularidad. Un tema interesante, sin dudas,y donde se juntan temas interesantes no centrales al trabajo diario de un galeote informático.

La singularidad tecnológica es el hipotético momento donde las computadoras se harán inteligentes y conscientes de sí mismas. Es un punto singular, un cambio cualitativo, donde, además, las máquinas inteligentes serán capaces de mejorar su propia inteligencia. Este, que es un concepto que ha estado dando vueltas en la cultura popular desde hace mucho tiempo, fue formalizado por Vernon Vinge, profesor de matemáticas, ciencias de la computación y escritor de ciencia ficción.

Se me ocurre divagar sobre la historia de la singularidad: tal vez se remonte a las primeras máquinas, que hacían algunas cosas que nosotros los humanos hacíamos, pero mucho más rápido y con asombrosa precisión. Como esas cosas que las máquinas hacían bien y rápido en algún momento se asociaron, o tal vez se asocian aún, a la inteligencia (hacer cuentas rapidamente, por ejemplo), temimos que en algún momento nos saquen la misma ventaja en otro montón de cosas asociadas a la inteligencia que todavía no hacían (y todavía no hacen o no hacen bien), y los humanos sí.

Vinge, en su paper de 1993, sostenía que la singularidad se daría entre 2005 y 2030. Y que esta, tomaría alguna de las siguientes formas:

Computadoras que alcancen la conciencia y sean mucho más inteligentes que los seres humanos. Es decir, que su creciente capacidad de cálculo alcance la del cerebro humano, y a partir de ahí, pueda entenderse a sí misma y mejorarse.
Redes de computadoras que alcancen la conciencia (sep, la Skynet deTerminator). Lo mismo que antes, pero en lugar de una sola computadora con muchos procesadores, algo así como un MPP.
Interfaces humanas que integren humanos y máquinas: un 'coprocesador' para el cerebro humano. Algo que, de alguna manera se enchufe a tu cerebro y sea particularmente bueno para cosas que tu cerebro es lento: por ejemplo, para hacer cálculos rápidos. En realidad, algo se ha avanzado en este campo, como por ejemplo los implantes cocleares que ayudan a recuperar la capacidad auditiva. De todas maneras, estos implantes no han alcanzado aún ni por lejos una capacidad comparable a la del oido, en parte porque no sabemos muy bien como conectarlos.
Algún mecanismo que, por medio de la manipulación biológica, pueda incrementar la inteligencia.. Esta es mi preferida, por lejos: asume que de alguna manera que no conocemos mejoraremos algo que no entendemos del todo. Para aplaudir.

Los argumentos que Vinge da para apoyar la singularidad se basan, basicamente, en la creciente automatización, en la velocidad de propagación de las ideas y en la ley de Moore: en algún momento, conjetura, la capacidad de proceso de una computadora superará a la capacidad del proceso del cerebro humano.

Mantengo cierto escepticismo sobre las aseveraciones de Vinge. Para comenzar, no sabemos, y no define él, que cosa es la inteligencia y la concienca. Más aún, se ha argumentado por ahí, de una forma no facilmente refutable, que nuestro razonamiento va más allá de lo computable: no es que haya algo inmaterial, sino que nuestros sistemas formales no son lo suficientemente abarcativos para describir el funcionamiento de nuestro cerebro. Como decía, no es una invocación a lo religioso o espiritual, sino una propuesta de que existen mecanismos que nuestros sistemas formalizados no pueden describir.

Otro punto débil es la fe algo exagerada en la ley de Moore: nada dice que vaya a seguir indefinidamente, y es interesante ver que no hay especialistas en el cerebro entusiasmadísimos con la singularidad, la mayoría son matemáticos o gente de ciencias de la computación. Es probable que se deba a que los especialistas en el cerebro tengan una idea del tamaño de nuestra ignorancia en el asunto y no vean demasiadas razones para creer que estamos cerca de entender como funciona el cerebro.

De acuerdo a lo que sostienen los singularistas, las neuronas son como transistores, que absorben, procesan y reemiten pulsos eléctricos. Un detalle no menor es que un transistor se conecta a otros dos transistores y cada neurona se conecta a otras diez mil. Estos pulsos eléctricos, según los singularistas, servirían como la unidad de información tanto del cerebro, como de las computadoras. Como es que esos mecanismos se transforman en recuerdos, gustos, emociones, razonamientos nadie lo sabe, y no hay mayores elementos para suponer que se parezca a un algoritmo.

Es claro que el cerebro es una máquina, lo que es menos claro es que clase de máquina es.

Más aún, la codificación del cerebro, es decir, qué lleva de esos pulsos a nuestra conciencia es un campo de estudio abierto. En algún momento se descubrió que el cerebro usa un código de cantidad (se interpreta un concepto en virtud de cuantas neuronas estén activadas en un determinado momento). Luego se descubrió un código de temporalidad: no solo depende la cantidad, sino el órden de activación (el código de cantidad asigna a 101 y a 110 el mismo significado, pero el temporal no), y se sospecha que puede depender también del ritmo de activación: el tiempo que media entre la activación de las neuronas.

Se nota en Spectrum menciona que el código temporal nos acercaría al límite teórico de Shannon.

Esta mayor cantidad de posibilidades de representación hacen que las unidades de información que puede manejar el cerebro sean órdenes de magnitudes superiores a las que puede manejar una computadora, aún con cientos de microprocesadores. Aún cuando no sea cierto el argumento cualitativo (el que sostenía Penrose, que la conciencia no es algorítmica), el argumento cuantitativo es claro: no estamos cerca aún de siquiera saber cuantas unidades de información maneja nuestro cerebro.

Por último, es interesante ver que opinan luminarias sobre la singularidad.

A mí me parece que la singularidad no es una gran idea por sí misma, pero tiene la virtud de hacernos pensar en temas muy interesantes.

Computer Disease

2008-08-05T11:38:00.001-07:00

Well, Mr. Frankel, who started this program, began to suffer from the computer disease that anybody who works with computers now knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is you play with them. They are so wonderful. You have these switches - if it's an even number you do this, if it's an odd number you do that - and pretty soon you can do more and more elaborate things if you are clever enough, on one machine.

And so after a while the whole system broke down. Frankel wasn't paying any attention; he wasn't supervising anybody. The system was going very, very slowly - while he was sitting in a room figuring out how to make one tabulator automatically print arctangent X, and then it would start and it would print columns and then bitsi, bitsi, bitsi, and calculate the arc-tangent automatically by integrating as it went along and make a whole table in one operation."

Los Alamos from Below. Reminiscenes 1943-1945. Richard Feynman

El fragmento que abre este post está tomado de los recuerdos de Richard Feynman de su paso por el Proyecto Manhattan. Mr Frankel, Stanley Frankel, era un físico que integró el equipo del proyecto, al igual que Feynman (como señala la página de wikipedia, tuvo problemas con la caza de brujas de los 50, que también le generó problemas a Oppenheimer: curiosa forma de tratar a los héroes de guerra). El buen Stanley introdujo en el Proyecto Manhattan el uso de las computadoras para calcular, entre otras cosas, los resultados de la explosión de la bomba, que eran muy difíciles de calcular con las máquinas mecánicas Marchant.

Frankel, como cuenta Feynman, sucumbió a la misma enfermedad que nosotros, los que nos dedicamos a esto: el encanto del jugueteo, la atracción lúdica de la computadora. El placer de enfrentarnos a retos difíciles, inútiles, y agradabilísimos. Sigue Feynman:

Absolutely useless. We had tables of arc-tangents. But if you've ever worked with computers, you understand the disease -- the delight in being able to see how much you can do. But he got the disease for the first time, the poor fellow who invented the thing.

Yo tiendo a asociar esta la 'enfermedad de la computadora' con nuestra insoslayable tendencia a lo que Brooks llama 'gold plating' (la tendencia a perderse en los detalles, a agregar más de lo necesario, a sacarle punta al lapiz a niveles atómicos). El gold plating puede ser, o mejor, seguramente es, uno de los ingredientes para la catástrofe en los proyectos. Pero para controlarlo, pienso, debemos entender de donde viene: es la expresión de la enfermedad que inauguró Frankel.

Estimaciones y futurología

2008-08-04T08:37:00.000-07:00

Either estimate from a spec of provide data on prior work and let the customer judge the range. If the customers then wanted detailed estimates, they would have to pay for the specification and design work required to make them. Unfortunately, it will take the software community some time to build the skills and credibility to work in this way. Until we do, however, we will continue to have estimating and planning problems

Watts Humphrey, Estimating with objetcs.

Con los otros galeotes estuvimos discutiendo el tema de las estimaciones estos últimos días. El post anterior es un poco deudor de esas discusiones. Como toda discusión estuvo motivada por un problema, y un problema grave, o como se diría ahora, en una enorme oportunidad de mejora: la oportunidad de mejorar las estimaciones de nuestros trabajos y mejorar, a niveles aceptables, acota la desagradable voz que escucho y de la que ya hablé, la planificación de nuestros proyectos.

Fatigando la ignorancia, creo haber llegado a la conclusión de que todos los métodos de estimación se basan en los siguientes pasos:
1. Una descripción del objetivo (en términos propios y de su contexto, que el sistema es él y su circunstancia)
2. Una descripción de como implementar o llegar al objetivo
3. Una descripción de tamaño de los componentes o pasos para llegar al objetivo
4. Una relación entre el tamaño y esfuerzo

PROBE, COCOMO II, Puntos de Función, historias del usuario, todos, de una manera u otra siguen estos mismos pasos.

Primero, nos hacemos una idea del problema a solucionar, y una descripción somera de las capacidades del software que debemos construir. El desarrollo de requerimientos no es mi tema, por lo que hablaré del asunto aquí.

Luego, hacemos un diseño conceptual. Decidimos que objetos o componentes integrarán las solución, cuales reutilizaremos (con o sin modificaciones), y que construiremos desde cero. De acá sacamos una lista de componentes, objetos, tablas, archivos, interfaces, y demás que debemos construir.

Luego hacemos una una estimación del tamaño. Es difícil argumentar que el tamaño de un software se mide en el tiempo que se tarda en desarrollarlo, casi tanto como es difícil argumentar que la distancia entre dos ciudadades se mide por el tiempo que yo tardo en llegar desde una a la otra: el tamaño es una medida objetiva relacionada, sí, con el esfuerzo de desarrollo, pero en definitiva distinta. Si la analogía entre distancia y tiempo de viaje no resulta adecuada, se puede pensar en otra: masa y peso. La masa es la cantidad de materia (el tamaño en nuestro software), independiente de la gravedad (la performance del equipo), mientras que el peso es una medida que tiene en cuenta la masa y la gravedad (el tiempo que tardamos en hacerlo)

Una buena medida, según mucha gente son las líneas de código estandarizadas. El problema está resuelto: estimamos la cantidad de lineas de código que tendrá el software que implementará unos requerimientos poco claros con un diseño aún no decidido y listo, no?. Bueno, no. Entre otras cosas por lo ridículo que sería sostener que para calcular el tiempo que tardaremos en desarrollar algo, primero debemos saber cuantas líneas de código tiene ese algo, Humphrey propone objetos como 'apoderados' o 'representantes' de las líneas de código (proxies, los llama).

Una disgresión con respecto a las lineas de código: es probable que haya una correlación entre las líneas de código escritas y el esfuerzo insumido, y tal vez sea posible defender su utilidad como métrica post-mortem de los proyectos,para comparar la performance de proyectos entre sí, si mantenemos igual las demás variables (lenguajes, entornos operativos, frameworks, y alguna más que ahora se me escapa). Sospecho, de todas maneras, que esta métrica post-mortem era más certera antes de los lenguajes con introspección.

Es claro como la estimación de tamaño ocurre si usamos puntos de función o puntos de caso de uso, pero diría que aún las historias del usuario tienen una etapa de estimación de tamaño: Kent Beck propone en Planning Extreme Programming, basar la estimación de historias de usuario en historias de usuario que hayamos implementado en el pasado, que sería algo así como lo que hicimos con mis compañeros galeotes, pero intuitivamente: pensar el tamaño de un componente, o de una historia de usuario, en términos de historias ya realizados. Esto es, decir, por ejemplo que una historia X que acabamos de recibir tiene un tamaño que cumple cierta relación con el tamaño de una historia anterior. Si bien se mira, las medidas no son más que eso: la relación entre una magnitud actual y una magnitud elegida por algún tipo de convención (cuando decimos que algo mide un metro treinta centímetros, decimos que se trata de una distancia igual a la distancia recorrida por la luz en el vacío durante algo así como 4,33nano segundos )

En el último paso, relacionamos el tamaño con el esfuerzo necesario, con una medida que podemos llamar de varias maneras, pero que en definitiva no es sino una expresión de nuestra performance de desarrollo. Acá, como en el resto, la estadística es fundamental y depende de cuan bien hayamos medido nuestra experiencia.

En definitiva, la clave para mejorar está en capitalizar nuestra experiencia, de una manera sistemática que nos sirva para formar juicios en el futuro, como en cualquier práctica que tenga que ver con la tecnología y la ingeniería.

Llave en mano

2008-07-24T19:52:00.000-07:00

Al menos en mi experiencia y entorno, los proyectos llave en mano son comunes. Me refiero por proyectos llave en mano a esos donde se compromete un precio y calendario con el cliente, y luego de ganar algo así como una compulsa de precios, comienza el desarrollo del software.

Estimar correctamente es un punto clave en este tipo de proyectos: una mala estimación hace perder dinero, tiempo, enojar al cliente por problemas de calendario y todo eso lleva a una caída en la calidad que aumenta los costos y hace enojar aún más al cliente.

Scott Ambler tiene una opinión bastante clara y razonada sobre los proyectos llave en mano. Ambler dice cosas ciertas: este tipo de proyectos te lleva a escribir todos los requerimientos de entrada, a pensar un diseño y una arquitectura y a implementar un mecanismo bastante restrictivo de gestión del cambio. Todo eso herético desde el punto de vista del desarrollo ágil. Yendo un poco más allá de mi último comentario, algo improcedente y sarcástico, se puede argumentar con razonable facilidad que intentar elucidar todos los requerimientos y pensar una arquitectura de un software que no existe antes de hacer siquiera una parte es una estrategia que traerá problemas, más temprano que tarde.

Por otra parte, no es un secreto que las estimaciones hechas a priori suelen diferir bastante del esfuerzo finalmente necesario.

Por eso, puedo estar de acuerdo con que la idea del proyecto cerrado es una idea perniciosa (puedo pensar en más de un ejemplo donde todos pierden: el cliente queda disconforme y el proveedor gastó más de lo que había proyectado).

Mirando desde el otro lado, si pensamos como el cliente, no es difícil entender por qué se desea saber por adelantado cuanto va a salir la joda: vamos, quien contrataría a un arquitecto (de casas y edificios) que dijera 'bueno, a medida que me vas pidiendo que construya algo en la casa, que agregue algo, te voy diciendo el precio'?. No vale argumentar que una casa es diferente al software, estoy hablando de dinero, que es bastante parecido en todos los ámbitos: quien se embarcaría en un proyecto sin tener idea de cuanto saldría y sin tener al menos la expectativa de tener dinero suficiente para no ahogarse a la mitad del río?. Yo no.

Aunque, como comenta Ambler, los proyectos cerrados puedan ser caros para el cliente porque el proveedor no tiene más remedio que cotizarle el riesgo e implementar algún mecanismo de control de cambio (efectivamente, como él dice, son mecanismos que tratan de impedir el cambio y no controlarlo). Más aún, con un mecanismo eficaz para impedir el cambio es altamente probable que el sistema construido diverja de las necesidades del usuario. Pero aún así, la previsibilidad financiera ( saber de antemano cuanto me va a costar) es terriblemente atractiva. Lo que se está pagando (lo que tanto cliente como proveedor están pagando), es la falta de información.

Se podría contra-argumentar que la idea de una metodología con foco en el control de cambios no es impedir el cambio, sino cobrarle al cliente por el mismo. No está mal, en definitiva, y eso nos acercaría a una estrategia ágil, donde ante cada cambio cobraríamos el diferencial de implementarlo ( costo de implementar lo nuevo menos el costo de no implementar lo que ya es necesario y no está implementado), lo que, incluso, penalizaría el cambio en etapas tardías del proyecto. Estaría incluso mejor si pudiéramos definir claramente, y por adelantado, qué es un cambio: no se puede cambiar lo que no se definió y el problema, muchas veces, no es que se haya definido un aspecto de un desarrollo en forma errónea, sino que no se lo ha definido de ninguna manera.

Claramente, necesitamos una solución. La solución ideal: que la industria se aleje de los proyectos cerrados, que el cliente nos contrate un equipo determinado por un tiempo pre-acordado y que adoptando el ciclo de vida de XP trabajemos haciendo lo que el cliente pide: pide más, hay más iteraciones. El problema es que parece demasiado bueno para nosotros, los informáticos, como para que se transforme en una práctica muy extendida.

A mitad de camino, tenemos la 'gestión de aplicaciones', o el servicio donde uno como proveedor implementa requerimiento a requerimiento. Es una buena idea, pero se necesita una confianza importante en la performance del equipo del proveedor. No es algo que un cliente le contrataría a un proveedor que recién conoce, me parece. Tampoco es, entiendo, demasiado común para desarrollos desde cero, sino que se adapta mejor a mantenimientos evolutivos y correctivos, donde, en definitiva, es más fácil estimar el esfuerzo de cada modificación.

Yo me imagino que la solución debería venir por alguna forma estándar en la industria de medir la performance de los grupos de trabajo en algo así como unidades estándares de software (que no sean lineas de código, por supuesto) producidas por unidad de tiempo. Volviendo al ejemplo del arquitecto ágil (el de casas y edificios) citado más arriba, creo que tal vez lo contrataríamos si pudiéramos acordar entre ambos, antes de comenzar el proyecto, una forma transparente de estimar los costos: nos aseguraremos que el arquitecto no se va a aprovechar de nuestra situación cuando sea muy caro abandonar el proyecto o cambiar de caballo. Que forma tendrían esas 'unidades estándares de software' (no de trabajo, sino de software)? Ni idea.

El objeto del negocio

2008-07-22T17:36:00.000-07:00

rito (Del lat. ritus).
1. m. Costumbre o ceremonia.
2. m. Conjunto de reglas establecidas para el culto y ceremonias religiosas.

Siempre es peligroso entregarse al mito, pero más aún en los momentos de entusiasmo.

Comisario Inspector Díaz Cornejo
(citado por Leonardo Moledo en 'Los mitos de la Ciencia')

Los ritos y los mitos se mezclan de muchas maneras. Se podría decir que éstos dan origen a aquellos. Es divertido repasar mitos ajenos, como hace el libro de Moledo citado más arriba. Y es un poco inquietante descubrir que los mitos ajenos no no son tan ajenos, como nos recuerda el libro de Moledo citado más arriba.

Los ritos, en la primera acepción según la RAE, pueden ser útiles como una forma de adquirir hábitos benéficos sin que tengamos que detenernos a pensar en su beneficio. Diríamos que lo bueno de los ritos es que pueden lograr que un tonto se beneficie sin que tenga que entender por qué, ni como sucede.

Este efecto benéfico de la ritualización no fue el que había dejado su huella en la aplicación que aceptamos para mantenimiento correctivo y evolutivo (aceptamos es un abuso de la primera persona ni yo ni mis compañeros galeotes decidimos nada), sino más bien todo lo contrario. Digamos que lo que observamos fue el efecto más usual del reemplazo del pensamiento por la ritualización: algo así como el desastre. Podemos rastrear el mito que da origen a los ritos practicados en el diseño de la aplicación de marras, pero eso vamos a dejarlo a los antropólogos.

La gente que escribió esta aplicación era gente de principios. Con convicciones muy firmes. Idealistas. Sabían que había que tener tres capas: presentación, lógica, y datos, a como diera lugar. Su esfuerzo patriótico no iba a cejar simplemente porque no tuviera sentido hacerlo, no. Ellos tenían certezas, y por sobre todo la certeza de que la duda es la jactancia de los intelectuales.

Así, por ejemplo, los objetos de la capa de lógica de negocio son cosas del estilo:

public class CuentaServ implements CuentaServInt {
   CuentaDao cuentaDao;

   public void almacenarCuenta(Cuenta c)
   {
      cuentaDao.almacenar(c);
   }

   public Cuenta obtenerCuentaPorId(int id)
   {
      return cuentaDao.obtenerCuentaPorId(id);
   }

   [...]

}

Cualquier hereje podría preguntar para qué tienen una clase donde todos los métodos tienen una sola linea. Qué valor agrega. Para qué sirve. Pero no ellos: ellos eran gente de fe, gente que sabe que el
progreso humano es una ilusión, que el secreto de la felicidad está en copiar exactamente la conducta de nuestros ancestros, que vivieron armonicamente en una época de sabiduría que nosotros arruinamos con la costumbre de someter su legado a escrutinio crítico.

Mi primera impresión fue decidir que si una clase tiene solo métodos de una linea, si es solo un pasamanos, probablemente no tenga ningún sentido. Al fin y al cabo, si la aplicación no tiene reglas de negocio, no debiera tener una capa que implemente la lógica de negocio.

Pero, vamos a ver: que aplicación no tiene lógica?. Es decir, la lógica en la aplicación es algo que existe, si no está implementada tal vez simplemente no esté implementada. Por ejemplo, dar de baja una cuenta sin preguntar nada suena por lo menos extraño. Asignar un nuevo paquete de servicios a un cliente sin verificar algunas condiciones antes, también.

Me estaba desesperando, cuando encontré métodos de Business Objects que sí tenían más de una linea de código. Un alivio. El patrón estaba justificado. Al final, me decía la vocecita esa que siempre escucho (no, no es la conciencia, es un enanito que se sienta sobre mi hombro y que solo yo veo, porque él tiene poderes mágicos), viste que tenía motivos, que no sos tan vivo como crees?. Acá está la prueba:

public List obtenerCuentasEnRojo()
{
   List l = cuentaDao.obtenerCuentasEnRojo();
   for (Iterator it = l.iterator(); it.hasNext();)
   {
      Cuenta cu = (Cuenta)it.next();
      Cliente c = cu.getCliente();
   }
   return l;
}

Esto se ponía bueno: el críptico cu.getCliente() era para forzar a hibernate a buscar el cliente en la base de datos. Algo doblemente bueno, ya que hacía a mano lo que podía hacer en un join, transformando una única query en tantas como cuentas se obtengan, impidiendo el ordenamiento por nombre si es que se pagina el resultado y, como extra y por el mismo precio, haciéndolo antes de forma que la vista no dispare algún query de hibernate, cosa que se podría haber solucionado con un open session in view (está implementado en Spring)

De la colección de errores, mi preferido es el evitar escribir el join en la base de datos. Debo admitir que la alegria de ver el patrón justificado se vio algo perturbada por el hecho de que implementar a mano un join es una de las cosas más estúpidas que se pueden hacer: es más trabajoso (uno paga dos veces, una por el motor de la base y otra por las horas de desarrollo), suele quedar con más bugs que los que trae el join en la base de datos, tardar más, ser más vulnerable a cambios en el volumen de datos, es más dificil ordenar y paginar por algún atributo de la segunda tabla, y unas cuantas cosas más.

Subyacen a estas prácticas unos cuantos mitos y esperanzas descabelladas: portabilidad entre base de datos (mi preferida, merecedora de un post enteramente dedicada a ella), adaptación al cambio (sí, es muy fácil adaptar un montón de código innecesario), prolijidad (que alguien me explique como se mide). Tal vez, al fin y al cabo, viendo las esperanzas descabelladas que sobreviven por ahí afuera en cuestiones algo más trascendentes que un business object, no tengamos derecho a esperar que estas, nuestras esperanzas descabelladas, desaparezcan en un futuro cercano.

Métricas, procesos y de como se juntan

2008-07-07T11:57:00.000-07:00

"Les recomiendo hacer este estudio si y solo si van a tomar conducta a partir del resultado", nos dijo hace un tiempo el médico genetista. a mi pareja y a mí, cuando estábamos iniciando los trámites para un estudio genético invasivo que entrañaba cierto riesgo.

Este buen doctor podría dedicarse a la consultoría en informática, o, al menos, podría aportar su criterio en lo que refiere a la definición, recolección e interpretación de métricas de procesos. Su criterio es simple y útil: uno no debería medir algo si luego no piensa hacer nada con esa medición. Las métricas que se recolectan pueden no ser útiles hoy, pero debería existir al menos expectativas de usarlas en un futuro, y estas expectativas deberían ir acompañadas de alguna idea de como se espera que sean útiles. Más allá del abuso de su jerga médica (en castellano, lo que él dijo se diría más o menos como "si no van a hacer nada con el resultado, les recomiendo no hacer este estudio ya que entraña algún riesgo") su idea es aplicable a casi cualquier ámbito, con excepción, quizá, de la ciencia básica.

La respuesta a la pregunta sobre que métricas se deben recolectar en un proceso de desarrollo de software es sencilla: las que sean útiles para tomar decisiones. Lo que es un poco más complicado es la instrumentación de esta respuesta. Vamos a tratar de aplicar una variación libre del método GQM, que, como todo, tampoco es rocket science. Un mapa de ideas siempre es bueno para ordenar las idem:

Lo que se desea, basicamente, es ganar dinero. La rentabilidad en un proyecto de software se puede ver amenazada por una mala estimación inicial ( los proyectos a precio cerrado tienen sus problemas, como bien nota Scott Ambler, pero son la forma más común hoy, al menos en el entorno donde yo me desenvuelvo. Será tema para otro post), por retrabajos (generados por mala calidad de lo producido o por cambios en los requerimientos) y retrasos en el calendario que, además de posibles multas, entorpecen la disponibilidad de las personas del equipo de trabajo y los recursos asociados.

Después de mucho pensar (o de poco pensar pero durante mucho tiempo), derivé un conjunto de métricas con las que me siento cómodo:

Cantidad de defectos, desagrupados por etapa del proyecto (cuando antes se producen, peor es) y tipo de entregable (defecto en software, en especificación funcional, en especificación técnica, o en el proceso mismo). Asimismo, me interesa el tiempo promedio de solución de un defecto.

Sobreesfuerzo generado por defectos, es decir, el esfuerzo necesario para corregir los defectos, desagregado por actividad.

Cantidad de cambios a los requerimientos, también desagrupados por etapa del proyecto y cantidad de cambios aceptados y rechazados.

Velocidad de avance del equipo, medida por la cantidad de historias del usuario o de requerimientos implementados por unidad de tiempo y como avance ganado, definido como tiempo insumido / (tiempo insumido + tiempo estimado para completar ).

Milestones cumplidos en tiempo, demorados y demora promedio.

Cantidad de cambios al plan del proyecto, y el motivo de los mismos (cambios a los requerimientos, cambios a la dotación del equipo de trabajo, errores en la estimación).

Desvío de la estimación original, por componente y actividad, para lo cual el sistema de registración de horas está alineado con la forma de estimar: se imputan horas con el mismo concepto y granularidad con que se estima el proyecto.

Es probable que al mapa le falten algunos objetivos (será más fácil ganar dinero si entrego un software que le entregue valor al usuario, no simplemente algo que cumpla con las especificaciones, por ejemplo), y seguir el rastro de esos objetivos probablemente nos agregue nuevas métricas.

Por otra parte, tengo un conjunto de métricas, las que por ahora no son útiles, pero espero poder utilizarlas en el futuro:

Cobertura de código por el testing: en entornos manejados (java, .net), asociado al proceso de integración continua, se mide el porcentaje de código cubierto por las pruebas unitarias y de regresión. Mi esperanza es, en algún momento, relacionar esto con la cantidad de bugs detectados por los procesos de prueba y certificación del usuario, para derivar un valor que minimice la suma entre el esfuerzo necesario para corregir bugs y el esfuerzo de construcción de pruebas unitarias y de regresión.
Cantidad de no conformidades detectadas por las herramientas de inspección automática, como PMD, Checkstyles, FxCop, Macker, con la misma esperanza que ya mencioné para la cobertura. Relación entre puntos de caso de uso y horas por actividad: guardo la esperanza de construir una base de datos lo suficientemente grande que pueda servirme de base para hacer una estimación por puntos de caso de uso.
Métricas de complejidad y tamaño de la solución, como cantidad de clases, paquetes, componentes desarrollados sobre los especificados. Aquí la idea para el futuro es poder determinar cuantitativamente cuan confiables son mis espeficiaciones técnicas y cuanto del producto real terminan por cubrir.
Espero poder madurar las métricas de defectos, para relacionarlas con la cantidad de pruebas realizadas y determinar si el no encontrar más defectos significa que el producto está estable o no se están buscando correctamente y armar tendencias de ocurrencias de errores.

De todas maneras, y como resumen, vale la pena recordar el concepto que vertió el buen doctor que nos atendió: el esfuerzo de recolectar una métrica sirve si ésta puede servir de base para una toma de decisión. Y por cierto, el objetivo de estas métricas (o de cualquier otras) no es cumplir con CMMI, signifique esto lo que signifique, sino dar información útil, que sirva para tomar decisiones, sobre la performance del proceso y el estado del proyecto.

De anécdotas, estadísticas y conclusiones apresuradas

2008-06-28T14:05:00.000-07:00

No conozco a nadie que haya votado a Cristina Fernandez en las últimas elecciones para presidente. Entonces es evidente que ha habido fraude.

No, no voy a hablar de política, y de hecho podía haber elegido un ejemplo más neutral para ilustrar el tema de este artículo, como por ejemplo, una reunión social donde alguien sostenía que la mayoría, o al menos una minoría apreciable de la población argentina tenía un título universitario. Ella, médica, no podía aceptar que menos del diez por ciento de la población tuviera uno, porque claro, la mayoría de sus conocidos y amigos tenía uno (y uno de médico, para más señas).

No es que ella fuera tonta, sino que estaba siendo víctima de un sesgo cognitivo bastante común: preferimos anécdotas a estadísticas, aún cuando las primeras no describen adecuadamente la realidad cuando hablamos de conjuntos muy grandes. Como en este blog abogamos por el pensamiento crítico y sostenemos que cualquier afirmación debe ser fundamentada, voy a tratar de fundamentar el por qué conviene estar alerta de este sesgo para así poder evitarlo (y por que conviene evitarlo)

Como sostiene John Allen Paulos al analizar la relación entre anécdotas y estadísticas, tanto las anécdotas como las estadísticas nos brindan información: las anecdotas incluyen muchos detalles de pocos sujetos (en sentido amplio: personas, animales, objetos) y utilizando estadísticas podemos conocer pocos detalles acerca de muchos sujetos. La descripción del primer día de clases de un niño nos dice mucho acerca de su caracter, gustos, temores, expectativas y otros aspectos de su personalidad, mientras que el ingreso medio per cápita de un país nos dice mucho acerca de la capacidad de compra de todos sus habitantes.

El problema empieza cuando pretendemos que con pocos casos sabemos mucho de la situación completa. El afirmar que una determinada generalización es cierta es, en términos más formales, sostener que existe una correlación entre dos o más variables. Así, por ejemplo, cuando sucumbimos a alguna de las ilusiones del patriotismo, que, como todos sábemos, no tienen término, estamos sosteniendo que existe una correlación, pongamos, entre las variables 'nacionalidad' e 'inteligencia'.

No es difícil demostrar formalmente (no lo haremos aquí, entre otras cosas porque es el objetivo de este blog y excede con mucho las capacidades del autor el ponerse a explicar matemáticas) que las correlaciones son menos confiables conforme el número de variables a correlacionar se acerca al número de casos de la muestra. Paulos ,en el paper enlazado más arriba, nos propone un ejemplo para ilustrar intuitivamente este fenómeno, donde correlaciona dos variables (inteligencia y timidez) usando dos sujetos de muestra.

Podemos conjeturar qué es lo que nos hace pensar de esta manera. Somos producto de una evolución de millones de años, la mayor parte de la cual se dio en condiciones muy diferentes a las que nos construimos estos últimos pocos cientos de años. Para nuestros antepasados, hasta hace tal vez pocos miles de años, el pequeño grupo de personas, la pequeña porción de la tierra y los pocos animales diferentes que veía una vez eran una porción representativa de los que verían por el resto de su vida, e incluso, de los que de una manera u otra ejercerían alguna influencia en su vida. Nuestro cerebro se moldeó en una época donde confundir anécdotas con estadísticas, generalizando rapidamente, era una ventaja competitiva que permitía tomar decisiones rapidamente.

Hoy enfrentamos una situación muy distinta, donde los sujetos y sistemas con los que estamos relacionados son muchos más de los que podemos imaginar ( se puede intentar lo complicado que es imaginarse un grupo de dos millones y medio de personas, por ejemplo... cuantas canchas de fútbol llenarían si se utiliza también el campo de juego? cuanto ocuparían si hicieran una manifestación ). En las sociedades en las que vivimos, un porcentaje ínfimo de personas constituye, en términos absolutos, una cantidad que nos parecerá enorme. Como los humanos solemos rodearnos de personas parecidas a nosotros (en nuestro trabajo compartimos el tiempo con gente de similares gustos y formación, nuestra familia suele parecerse a nosotros, buscamos parejas que se nos parezcan, vamos a clubes y asociaciones donde nos sentimos a gusto), completamos el cuadro con el sesgo de disponibilidad: elaboramos nuestras conclusiones tomando como base lo que observamos en un entorno que, aún cuando sea amplio, es ínfimo comparado con la totalidad y que además ha sido elegido a nuestra imagen y semejanza.

No es que todas las generalizaciones sean malas. Las generalizaciones nos permiten desarrollar vacunas, antibióticos, políticas sociales, incluso hasta a veces nos permiten comunicarnos. Solamente, tal vez, deberíamos recordar que llegar a una buena generalización (una buena generalización es aquella en la que podemos confiar ya que ha sido elaborada evitando los sesgos que mencionamos arriba) cuesta mucho trabajo y que las generalizaciones erróneas son terriblemente peligrosas.

Una buena descripción de los sesgos cognitivos que nos atormentan se puede encontrar en el libro Don't Believe Everyhing you Think (Six mistakes we make in thinking) de Thomas Kidda.

La agilidad y CMMI

2008-06-24T08:42:00.000-07:00

Luego de haber pasado por unos cuantos proyectos de desarrollo, he visto cosas que ustedes sí creerían (porque ustedes también las vieron, que no me refiero a naves de guerra en llamas más allá de Orion, ni rayos C resplandeciendo en la oscuridad). Y luego de haber visto tan terribles cosas,tengo un par de conclusiones apresuradas:

Cualquier proyecto de desarrollo de sistemas debe manejar el cambio, no intentar impedirlo. Intentar impedir el cambio (en el entorno, en las especificaciones, en el equipo de trabajo), es similar a buscar la fuente de la eterna juventud.
Muchas organizaciones necesitan adoptar marcos que les permitan, entre otras cosas, darle visibilidad a la ejecución de proyectos, delimitar responsabilidades, ser predecibles y construir una historia que pueda ser explotada con el objeto de saber donde deben mejorar.

La primera conclusión me hace mirar con simpatía las metodologías ágiles (debo -admitir que solo conozco XP) y la segunda me hace pensar en la necesidad de un marco formal y más riguroso, al estilo CMMI (que no es exactamente un metodología, sino un marco ). Un prejuicio ( el marco más comunmente usado para tomar decisiones ) me decía que no se podía estar a la vez de un lado y del otro: o sos ágil y desordenado o sos lento, paquidérmico, y eso sí, muy ordenado.

Conforme fui conociendo más de CMMI y XP, el prejuicio se fue debilitando ( es notable cuan perniciosa es la información y el conocimiento para la supervivencia de los prejuicios ), y hasta encontré que el SEI ya lo había contestado (no es exactamente CMMI, sino CMM, pero es una lectura recomendable).

Como sabemos, CMMI establece los famosos cinco niveles, con áreas de procesos en cada una de ellas. Cada área de proceso tiene objetivos específicos y prácticas específicas para cumplir sus objetivos. XP, por su parte, consiste en una serie de buenas prácticas asociadas al desarrollo del software.

Ninguna de estas es, como dirían los americanos del norte, rocket science: se trata de sentido común y lecciones aprendidas por la industria durante muchos años, llevadas al extremo en el caso de XP.

XP y CMMI, punto por punto …

… o más o menos, simplificando las áreas de proceso de manera caprichosa, vamos a recorrer las similitudes:

Requerimientos: CMMI plantea dos areas relacionadas con requerimientos en los niveles dos y tres: gestión de requerimientos y desarrollo de requerimientos, con foco en la elicitación, definición, verificación, validación y control de los requerimientos. XP plantea integrar un usuario o representante del usuario (como un jefe de producto) al equipo, con el objeto de que sea él mismo quien defina sus requerimientos, esté disponible permanentemente para consultas y pueda dar feedback sobre la implementación de los requerimientos luego de cada release.

Planificación y control: con XP estamos planificando continuamente: antes de cada iteración se recolectan requerimientos (‘user stories’, para XP), lo que se explica con la metáfora del carrito de compras: se recolectan user stories hasta colmar la capacidad del carrito (o sea, la capacidad de trabajo del equipo). La planificación es explícita (se seleccionan las user stories a implementar en cada release) y se actualiza continuamente, se estima el esfuerzo requerido para cada story y se planifica cada iteración antes de comenzar. El avance de cada iteración se monitorea durante las stand up meetings. La métrica de project velocity (la suma de la estimaciones de las stories implementadas en la iteración) proporciona una idea de la performance del equipo de trabajo. El avance global del proyecto se mide de forma muy conveniente por la cobertura funcional, es decir, por el porcentaje de user stories implementadas.

Quality Assurance, Validación y Verificación: la práctica de pair programming, la propiedad compartida del código y la integración continua refuerzan el foco de XP en QA. El código es verificado dado que se programa en pares que se verifican muamente. Más aún, se pueden incorporar al proceso de integración continua herramientas de verificación estática. XP hace foco en los test unitarios (toda clase o componente debe tener sus test unitarios) y los test de aceptación, que pueden ser perfectamente automatizados.

Gestión de la configuración: las releases sucesivas y cortas requieren una gestión de la configuración importante, aún cuando XP no lo mencione explicitamente: sin una adecuada gestión de la configuración, las prácticas de releases cortas, propiedad compartida de código e integración continua son imposibles.

Gestión de Riesgos: si bien XP no incorpora una práctica específica de gestión de riesgos, la integración continua, la disponibilidad permanente del usuario y las iteraciones cortas son, en definitiva, las políticas de mitigación para los riesgos más frecuentes en los procesos de desarrollo de software. Asimismo se recomienda acomodar las stories más problemáticas en las primeras releases para tener tiempo de corregirlas, lo que ayuda a mitigar los riesgos más comunes en los proyectos de desarrollo

Métricas y Análisis de las métricas: o existe en XP una práctica específica de análisis de métricas, pero el proceso produce métricas que pueden ser analizadas para identificar áreas de mejora. Las métricas como project velocity, bugs encontrados, cobertura de los test, errores de integración son producidas por el proceso y las herramientas que lo soportan.

Donde comenzamos a diverger

Existen algunas divergencias entre CMMI y XP, en particular, en áreas de proceso que adquieren mayor importancia conforme el número de integrantes del equipo de trabajo crece.

No existe ninguna práctica en XP asociada a las areas de proceso con foco en la organización, que tienden a asegurar la adherencia de toda la organización al proceso y encausar las actividades de mejora en toda la organización.

XP no posee ningún foco en estructurar guías de arquitectura al inicio del proyecto, lo que puede ser necesario para equipos grandes que trabajen en un desarrollo desde cero y no en mantenimiento. Esto último puede corregirse implementando primero las user stories más significativas desde el punto de vista de la arquitectura y que sirvan como molde, pero aún así, en determinados contextos la documentación de diseño puede ser necesaria ( en otros, puede ser absolutamente innecesaria y contraproductiva).

La práctica del refactoring continuo puede no ser extensible a grandes equipos, donde sea difícil mantener la visión global del producto a construir, o, al menos, donde es complicado que todo el mundo la tenga.

Mis personalísimas conclusiones

XP propone unas cuantas ideas que cualquier equipo de desarrollo que no quiera verse inmerso en un gran quilombo haría bien en seguir, como la planificación continua, el monitoreo de avance en virtud de lo que se hizo y no de lo que se supone que falta, el testing, tanto unitario como de aceptación, el diseño simple y el no tratar de resolver problemas que uno no tiene hoy.

De todas maneras, puedo pensar en contextos donde implementar XP en todo su esplendor sería peligroso: en los proyectos llave en mano, donde se asume de antemano un compromiso en tiempos y costos, no solo no tendremos a un cliente sentado aquí para que nos diga que quiere, sino que no podemos soportar el cambio continuo (tenemos que ganar dinero). Por otra parte, un compromiso inicial en tiempos y costos requiere un entendimiento inicial de todos los requerimientos, y un cambios en estos últimos podría significar un cambio en los primeros aspectos. En estos casos, seguimos sin poder anular el cambio, pero podemos saber cuando ocurre, por qué ocurre y que cambios adicionales (en tiempo y costos) se generan por un cambio en los requerimientos y el marco de CMMI nos ayuda a hacerlo.

Creo también que conforme el equipo crece en tamaño se necesita más foco en los aspectos organizacionales de la metodología, la gestión y el diseño y arquitectura

En definitiva, como dice el artículo del SEI linkeado más arriba, la postura extrema de XP requiere un management competente, y en eso se enfoca CMMI, por lo que un enfoque que complementario entre XP y CMMI puede ser valioso.

Fuentes:
Extreme Programming from a CMM Perspective, Mark C. Paulk
Planning Extreme Programming, Kent Beck
Extreme Programming Explained, Kent Beck

don Manuel, o la tragedia argentina

2008-06-18T06:49:00.000-07:00

Hoy se cumplen tres años de la muerte de don Manuel Sadosky.

Manuel Sadosky encarnó lo mejor de la Argentina: cuando el mundo se ocupaba de organizar pogroms y masacres justificados por motivos religiosos o por el resbaloso concepto de raza, cuando se separaban entre lores y comunes, entre nobles y plebeyos, el hijo de un ruso judío semi analfabeto se doctoraba en ciencias físico matemáticas.

Don Manuel, intelectual y progresista, participó de la época de oro de la universidad argentina. Se trataba de una universidad que producía conocimiento con la expectativa de que éste mejorara la sociedad, y no solo impartía clases. Don Manuel, había creado la primer carrera relacionada con la informática en el país, y había fundando el primer instituto de cálculo de la argentina y uno de los primeros de la región.

La época de oro se acabó violentamente cuando un general de pocas luces decidió que iba a terminar con ese nido de comunistas que era la universidad argentina. Don Manuel (que, entre otras cosas, era comunista) se exilió. Su instituto de cálculo y la mítica Clementina, la computadora que le daba vida, sufrieron la heurística que los imbéciles aplican para conducirse frente a lo que no entienden: Clementina fue destruida y el instituto cerrado.

Don Manuel volvió al país unos años después. Al poco tiempo, volvió a exiliarse frente a la amenaza de Triple A. Retornó al país en forma definitiva en 1983, para fundar la ESLAI (Escuela Superior Latinoamericana de Informática) con el objeto de atacar lo que con justicia él identificaba como una de las causas del subdesarrollo: la brecha científica y tecnológica, la falta de producción de conocimiento y de ciencia aplicada. Esta vez no hubo bombas, ni allanamientos violentos, ni amenazas de muertes: solo burócratas en el nombre de la eficiencia clausurando otra vez su valioso trabajo.

Crecí en un contexto que un patriota era el que ganaba guerras, o incluso, el que masacraba compatriotas. En este pequeño recuerdo me gustaría honrar la palabra patriota adjetivando con ella a don Manuel: alguien para quien pesaba más la maravillosa educación que había recibido en el colegio Mariano Acosta y durante sus años en la facultad que el maltrato al que su país lo había sometido después.

Don Manuel vivió lo suficiente para conocer un tardío reconocimiento a su inmenso aporte a este país.

En cuanto a Onganía, el generalito de marras, los dioses no consintieron que deshonrara al cadalso, muriendo en él y dejó de joder en 1995, demasiado tarde, de viejo y enfermo (*)

Domingo Liotta, el destructor de la ESLAI, siguió detentando el cargo de director del CONICET durante parte de la presidencia de Menem: cobijó a chantas e hizo algunos papelones públicos, como cuando presentó a Prigogine sin, por supuesto, haber leído ni siquiera su libro de divulgación. Hoy ejerce como decano de medicina de la prestigiosa universidad de Morón.

(*) Idea tomada de 'El Arte de Injuriar', de Jorge Luis Borges.

Que maestro!

2008-06-13T08:49:00.000-07:00

Me gusta encarar proyectos de reingeniería de aplicaciones: tienen algo de candor iluminista (*) por eso de la confianza en el futuro, no se escucha el solapado o no tan solapado pedido del cliente de arreglá tres horas la mierda que nosotros hicimos en seis meses , y por supuesto, uno supone que se le ocurrirá una idea genial en diez minutos que será mejor que el diseño evolutivo que tiene encima una aplicación que hace quince años corre sin problemas ( tendencia innata al creacionismo, o a la irracionalidad, que es lo mismo, que tiene uno).

La idea de diseño evolutivo está tomada de la idea de la evolución de las especies: una aplicación que está andando, sufriendo cambios desde hace diez o quince años y que pasó por ocho presidentes, dos devaluaciones, cuatro incautaciones de depósitos, siete burbujas con sus correspondientes explosiones, doce cambios importantes en la legislación impositiva y miles de cambios menores ha hecho un fantástico trabajo de adaptación al medio. Claro que, en definitiva, el relojero es ciego, por lo que en el proceso adaptativo se generan características que hoy se revelan imperfectas, o directamente como boludeces. Algunas de estas imperfecciones evolutivas son imperfecciones porque cambió el entorno y lo que antes era una ventaja hoy no lo es. Otras siempre han sido malas pero la desventaja que suponen no ha sido incompatible con la supervivencia, todavía.
Así, haciendo arqueología en una aplicación que estábamos reingenierizando, dimos con una obra, no del relojero ciego, sino del diseñador corto. Llegamos a una tabla que se llamaba algo así como xtmaetr, y sus campos eran algo así como:

ID (bien, lógico, normal)
XTMAEDECR (puedo deducir que la descripción)
XTMAE_1
...
XTMAE_9

Los ID eran correlativos, y el resto de los campos no tenían absolutamente ningún patrón: un mismo campo tenía una fecha en un registro, para pasar a tener una sucesión ininteligible de caracteres en el siguiente. Le preguntamos al padre de la criatura, quien orgulloso nos repondió: "esta tabla es el maestro". El maestro de qué? El maestro de todo, el master of the universe, alfa y omega, la real y lo posible, el sonido y la furia. A ver si me explico: esa tabla tenía todos los artículos, todos los clientes, todas las sucursales, todas las provincias, y así siguiendo, con un campo "tipo" que decía si estábamos en presencia de un cliente o de una pieza de repuesto de un motor diesel. Definitivamente, un maestro.

Una pena que no llevaran la idea un poco más allá y se limitaran a tener una tabla, como lo explica Tom Kyte: uno no tiene que diseñar nada, ni saber de diseño, ni conocer las características del software de base que está usando, simplemente tiene que hacer algo genérico.

(*) la entrada de la wikipedia de iluminismo no es correcta. Uso en este post a iluminismo como sinónimo de ilustración.

Eso que llamamos vida

2008-06-11T14:16:00.000-07:00

Seis veces hasta ahora he visto la muerte cara a cara, y otras tantas ella ha desviado la mirada y me ha dejado pasar. Algún día, desde luego, la muerte me reclamará, como hace con cada uno de nosotros. Es solo cuestión de cuando y de cómo. He aprendido mucho de nuestras confrontaciones, sobre todo acerca de la belleza y de la dulce acrimonia de la vida, del valor de los amigos y la familia y del poder transformador del amor. De hecho, estar casi a punto de morir es una experiencia tan positiva y fortalecedora del carácter que yo la recomendaría a cualquiera, si no fuese por el obvio elemento ,esencial e irreductible, de riesgo. Me gustaría creer que cuando muera seguiré viviendo, que alguna parte de mí continuará pensando, sintiendo y recordando. Sin embargo, a pesar de lo mucho que quisiera creerlo y de las antiguas tradiciones culturales de todo el mundo que afirman la existencia de otra vida, nada me indica que tal aseveración pueda ser algo más que un anhelo. Deseo realmente envejecer junto a Annie, mi mujer, a quien tanto quiero. Deseo ver crecer a mis hijos pequeños, y desempeñar un papel en el desarrollo de su carácter y de su intelecto. Deseo conocer a nietos todavía no concebidos. Hay problemas científicos de cuyo desenlace ansío ser testigo, como la exploración de muchos de los mundos de nuestro sistema solar y la búsqueda de vida fuera de nuestro planeta. Deseo saber como se desenvolverán algunas grandes tendencias de la historia humana, tanto esperanzadoras como inquietantes [...] De haber otra vida, fuera cual fuere el momento de mi muerte, podría satisfacer la mayor parte de estos deseos y anhelos, pero si la muerte es solo dormir, sin soñar ni despertar, se trata de una vana esperanza. Tal vez esta perspectiva me haya proporcionado una motivación adicional para seguir con vida. El mundo es tan exquisito, posee tanto amor y tal hondura moral que no hay motivo para engañarnos con bellas historias respaldadas por escasas evidencias. Me parece mucho mejor mirar cara a cara a la muerte en nuestra vulnerabilidad y agradecer cada día las oportunidades breves y magníficas que brinda la vida.

Carl Sagan.

Carl sigue comentando que tenía una tarjeta postal enviada por un pasajero del Titanic que, unos días antes del famoso hundimiento que le costó la vida a mucha gente, autor de la postal inclusive, y desde el barco mismo, contaba como la estaba pasando en grande. Menciona Carl que la tenía a la vista para recordar como 'pasándola en grande' puede ser un estado de lo más lábil y pasajero, y como eso lo ayudaba a disfrutar de la dulce acrimonia dela vida, como dice él. Mi pequeña tarjeta del Titanic, lo que me inspira y me motiva buscar y disfrutar de las oportunidades que él menciona, son las lineas de arriba, tomadas del libro Miles de Millones.

Miles de Millones es el libro póstumo de Carl Sagan, su libro más intimista, un fantástico legado de filosofía humanista, de amor por el conocimiento, por la ciencia y por la vida.

Lóbulo temporal

2008-06-10T19:13:00.000-07:00

Quien convenció al mundo, o al menos a algunos IT Architects, que el uso de tablas temporales era una buena idea??!?.

No creo que sea una práctica extremadamente común (el mundo no funcionaría) pero me he encontrado con algunos casos: la última vez, el otro día.

El asunto era más o menos así: una típica aplicación de guarda-recupera-datos, que es lo que hacen, pese a la pretención de los amantes de las multicapas, la mayoría de las aplicaciones comerciales (la existencia de Business Objects que son solo un pasamanos, o peor aún, que implementan cosas que la base de datos hace mucho mejor, será tema para otro post).

La maravilla de la informática con la que mi triste figura dio el otro día tenía un bloque con la siguiente lógica (bueno, sabrán disculpar el exceso del lenguaje que significa llamar 'lógica' a eso):

El usuario identificado en la sesión podía ser de tipo A o B
Se generaba un número único de operación (con una secuencia)
Si el usuario era de tipo A, se obtenian datos de la Tabla A con una condición y se insertaban en la Tabla TMP agregándole a cada registro de la Tabla TMP el identificador generado anteriormente (así no se mezclaban los datos entre sesiones, no vayan a creer que era una chapuza)
Si el usuario era de Tipo B, insertaba igualmente en la Tabla TMP pero pero obteniendo los datos de la Tabla B
Para finalizar, hacía un join entre la Tabla TMP, filtrando por el ID de operación, y otra tabla, agregando proyecciones y otras cosas para finalizar mostrando unos pocos resultados.
Al finalizar, borraba, vía delete, los registros de la Tabla TMP con el ID de operación (obviamente, no podía hacer un truncate porque la tabla la usaban unas cuantas sesiones)

Este portento del ingenio humano en forma de aplicación informática transformaba así una consulta en dos consultas, más unos cuantos inserts, más idéntica cantidad de deletes. Eso sí, la muestra de destreza tecnológica tenía un motivo: la reutilización de código ( no es claro como se reutiliza el último query, más todos los deletes? Que no debieran existir es apenas un detalle que no debe opacarnos la alegría que nos causa reutilizar código), y la lógica de la aplicación, que haría que si esto fuera una única query sería demasiado complicada ( es claro que es mucho más sencillo seguir un código que hace en muchas líneas lo que se podría hacer en una ).

En la contemplación y admiración de tal muestra de capacidad e inventiva pasé unos días, la semana pasada: los gustos hay que dárselos en vida.

Un Punto Azul Pálido

2008-06-09T07:45:00.000-07:00

Yet another blog without readers?. Algo así: no habrá por acá nada que no haya sido dicho antes, mejor y más exactamente, por lo que la única sección que creo valdrá la pena es la de links.

Mi interés primario es la informática, el desarrollo de software en concreto, por lo que los temas girarán normalmente en torno a ésta y las desventuras de esta mal paga e ingrata profesión (je, el victimismo, como me irrita). También es posible que comente sobre los libros que estoy leyendo: normalmente, informática, filosofía, y divulgación científica.