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.
Thursday, October 30, 2008
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)
