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.