Veladas esperanzas singulares

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

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

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

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

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

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

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

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

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

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

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

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

Oportunidades perdidas y mejoras inesperadas

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

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

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

"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

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

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

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

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

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

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

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

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

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

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:

1. Identificar las interfaces relevantes: pueden ser algunas pantallas, mecanismos de IPCs e integración (colas de mensajes, web services)
2. De las pantallas identificadas, abstraer la presentación y pensar unicamente la interfaz de la operación
3. 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.
4. 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
   
5. 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):

1. 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)
2. Bajar intempestivamente un componente y ver cuan fácil es determinar el problema
3. Determinar que posibilidad hay de ejecutar aisladamente un componente construido sin el software de base (obviamente, con máquina virtual y sistema operativo, unicamente)
4. 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'.