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.
Wednesday, November 12, 2008
Sunday, November 9, 2008
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.
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.
Monday, November 3, 2008
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.
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.
Thursday, October 30, 2008
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.
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.
Friday, October 24, 2008
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:
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.
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.
Tuesday, October 14, 2008
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.
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.
Thursday, October 9, 2008
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.
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.
Subscribe to:
Posts (Atom)
