Saturday, June 28, 2008

De anécdotas, estadísticas y conclusiones apresuradas

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.

Tuesday, June 24, 2008

La agilidad y CMMI

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

Wednesday, June 18, 2008

don Manuel, o la tragedia argentina

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.

Friday, June 13, 2008

Que maestro!

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.

Wednesday, June 11, 2008

Eso que llamamos vida

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.

Tuesday, June 10, 2008

Lóbulo temporal

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.

Monday, June 9, 2008

Un Punto Azul Pálido

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.