En todo y hasta en el proyecto más pequeño de desarrollo, las personas trabajan con personas. En todos y hasta en el campo más abstracto de investigación, las personas escriben software para las personas a las que ayudan en alguna de sus metas. La gente escribe software con gente para la gente. Es un negocio de personas. Desafortunadamente, lo que se enseña a programadores, a menudo, los equipa muy mal para hacer frente a las personas con las que trabajan. Afortunadamente hay un completo campo de estudio que puede ayudar.
Por ejemplo, Ludwig Wittgenstein plantea un buen caso en “Philosophical Investigations” (y donde sea): cualquier lenguaje que usamos para hablarnos no es, no puede ser, una formato de serialización para llevar un pensamiento o idea o imagen de la cabeza de una persona a otra. Ya deberíamos estar en guardia en contra del malentendido cuando “obtenemos requerimientos”. Wittgenstein también muestra que nuestra habilidad para entendernos del todo no surge de definiciones compartidas, surge de una experiencia compartida, de una forma de vida. Esto puede ser una razón por la cuál los programadores que están inmersos en su dominio del problema tienden a hacerlo mejor que aquellos que están fuera de ello.
Lakoff y Johnson nos presentan un catálogo de “Metáforas por la que vivimos”, sugiriendo que el lenguaje es ampliamente metafórico, y que esas metáforas ofrecen una percepción de cómo podemos entender el mundo. Incluso los términos aparentemente concretos, como “flujo de efectivo”, que podríamos encontrar en una plática sobre el sistema de finanzas, pueden ser vistos como metafóricos: “el dinero es un fluido”. ¿Cómo se hace que la metáfora influya en la forma en que pensamos sobre los sistemas que manejan dinero? O podríamos hablar acerca de capas en una pila de protocolos, como algunos de alto nivel y otros de bajo nivel. Algo poderosamente metafórico: el usuario está “arriba” y la tecnología está “caída”. Esto expone nuestro pensamiento acerca de la estructura de los sistemas que construimos. Esto puede también marcar un flojo hábito de pensamiento del que nosotros deberíamos beneficiarnos de vez en cuando.
Martin Heidegger estudió de cerca la manera en que la gente experimenta herramientas. Los programadores construyen y usan herramientas, pensamos en ello y creamos, modificamos y recreamos la herramienta. Las herramientas son objeto de interés para nosotros. Pero para sus usuarios, como Heidegger muestra en “Being and Time”, una herramienta se convierte en una cosa invisible entendida sólo en su uso. Para los usuarios las herramientas sólo se convierten en objetos de interés cuando no funcionan. Esta diferencia en énfasis es útil para tomar en cuenta cuando la usabilidad está a discusión.
Eleanor Rosch anuló el modelo aristotélico de las categorías en las que organizamos nuestra comprensión del mundo. Cuando los programadores preguntan a los usuarios sobre su deseos para con un sistema, ellos tienden a preguntar las definiciones a través de predicados. Esto es muy conveniente para nosotros. Los términos en predicado pueden ser convertidos fácilmente en atributos de una clase o columnas en una table. Este tipo de categorías son difíciles de entender, disjuntas y ordenas. Desafortunadamente, tal y como Rosh mostró en “Natural Categories” y trabajos posteriores, la gente no entiende el mundo, en general, de esta forma. Ellos lo entienden en formas basadas en ejemplos. Algunos ejemplos, como los tan llamados prototipos, son mejores que otros y, por lo tanto, las categorías resultantes son difusas, se superponen y pueden tener una rica estructura interna. Mientras sigamos insistiendo en respuestas Aristotélicas seremos incapaces de preguntar a los usuarios las preguntas correctas sobre su mundo, y estaremos luchando por llegar al común entendimiento que necesitamos.
Traducción: Espartaco Palma