Seguramente la fenomenología sea una de las corrientes filosóficas más importantes e influyentes del último siglo. Sus principales autores fueron un puñado de señoros blancos, centro europeos, más o menos acomodados, que desarrollaron sus carreras en diferentes cátedras universitarias: Husserl -al que puede considerarse el padre de dicha corriente-, Heidegger, Merleau-Ponty, Sartre, Gadamer...
Durante la Segunda Guerra Mundial, con el auge del nazismo, algunos de estos filósofos huyeron del viejo continente y la fenomenología extendió su influencia por las américas. Así que, a día de hoy, existe una amplia bibliografía y expertos que siguen estudiando esta corriente, no sólo en lengua alemana y francesa, sino también en inglés y castellano.
Y ¿Qué carajos tiene que ver la filosofía con la resolución de problemas -especialmente con los problemas tecnológicos-? Bueno... el de este post, no es sólo un título que busque generar expectación. Aquí trataré de exponer como, mantener una actitud fenemenológica, nos puede resultar útil a la hora de abordar ciertos problemas que surgen en el desarrollo de aplicaciones informáticas... O quizá no resulte útil pero, al menos, nos hará sentirnos parte de un ser más global al conectar nuestras miserias de desarrolladores con los grandes problemas de la humanidad: ¿Qué es el Ser? ¿Es posible el conocimiento? Quizá, así, nos ayude a llegar más lejos, nos de aire para sumergirnos más profundo y, finalmente, nos conduzca al éxito si lo abordamos como una cuestión trascendental y no un simple problema técnico.
Si pudiéramos definir la fenomenología en una sola frase diríamos con Husserl que hay que "ir a las cosas mismas". Y, las cosas mismas, en este nuestro caso, van a ser los problemas tecnológicos. Y, para ser más específicos: los problemas surgidos en el desarrollo de software.
Muchas veces creemos que debemos acumular un montón de conocimientos teóricos para afrontar los problemas que nos encontramos en nuestro trabajo diario. Padecemos un cierto síndrome de Diógenes del conocimiento. Un síndrome que vamos cultivando desde que nos incorporamos al sistema educativo: adquiriendo el conocimiento y luego demostrándolo en exámenes y pruebas varias. Pero no es algo exclusivo del sistema educativo. Se ve también en el mundo empresarial: en la compañía para la que trabajo, por ejemplo, la forma de promocionar consiste en defender ante un comité de "expertos" que manejas una buena retahíla de conocimientos teóricos en un área determinada. Y muchas entrevistas de trabajo acaban convirtiéndose en un enumerar tecnologías, saber situarlas en un cierto espectro de negocio -y que coincidan con la check list del entrevistador-. Incluso en algunas compañías se hacen exámenes -o pruebas técnicas- para seleccionar al mejor candidato, en base a ese saber teórico.
No es de extrañar que el sistema educativo y empresarial se parezcan tanto: el uno alimenta al otro de mano de obra y las compañías marcan la hoja de ruta de los centros de formación -en base a las necesidades de los mercados-. Y, sí, es necesaria una cierta base teórica, una serie de preconcepciones, generalidades, formas de hacer, vocabulario y conceptos comunes que nos orienten en el día a día de nuestro sector concreto y en el continuo movimiento de las nuevas versiones, productos y tendencias que van apareciendo en el mundo IT. Pero seamos realistas: en la era del internet y las IA, el saber enciclopédico ha perdido fuerza frente a otras habilidades como: buscar, filtrar y contrastar información, modelar o aprender haciendo... Ya no es tan fácil salir airosos de tirarse el pegote -porque con el móvil cualquiera puede acceder a internet y contrastar la información-.
De hecho, aunque manejemos un buen abanico de conocimientos, en nuestro quehacer diario debemos lidiar con muchas incertidumbres y tecnologías que no conocemos, o conocemos de forma vaga, o hace años que no utilizamos. Es imposible conocerlo todo: en los proyectos trabaja mucha gente, cada proyecto tiene sus propias dependencias, funcionalidades, módulos y una forma diferente de combinarlos para resolver necesidades concretas. Así que, cuando estamos implementando mejoras, cambios o nuevas características, nos puede pasar que "-Esta mierda no funciona y no tengo ni idea de por qué". Nos cabreamos y empezamos a buscar culpables para averiguar quién ha montado eso de forma tan enrevesada, nos bloqueamos, no sabemos por donde avanzar... Descubrimos que los flamantes contenidos teóricos que expusimos de forma brillante en la entrevista no sirven de mucho para manejarnos en la nebulosa de incertidumbre en la que hemos aterrizado. Aquí es cuando la fenomenología puede venir en nuestra ayuda: -¡Vayamos al problema mismo! Vayamos afianzando certidumbres, pongamos en suspenso aquello que dábamos por supuesto -pero de lo que no tenemos evidencia-. Con suerte, lograremos llegar a un punto en que descubramos que estábamos equivocados y que el error estaba en nosotros, que habíamos implementado algo con una concepción errónea de cómo funcionaba tal o cual herramienta -de la equivocación y el error es fácil salir; es mucho más complejo salir de los estados de confusión-.
Al final, la fenomenología va de eso: de aportar certeza, fundamentar las ideas en la realidad y determinar si es posible acceder a esta última desde nuestra subjetividad. El conocimiento siempre es "conocimiento de", siempre va dirigido a algo -acerca de lo que queremos saber-. Queremos saber de nuestro proyecto para identificar el problema, resolverlo y seguir adelante con lo que estábamos haciendo. Y, obviamente, no lo conocemos todo, sólo la superficie a la vista desde donde nos estamos aproximando... Todo apunta a que tendremos que enfocar desde puntos diversos y profundizar en ciertos aspectos que antes para nosotros eran perfectamente abstraíbles -caja negra-. Cuando finalicemos este proceso tendremos una idea más precisa de lo que el proyecto y las tecnologías que utiliza son. También la fenomenología nos señala eso: cómo las ideas que manejamos de las cosas están en continua construcción y adaptación, cómo se van determinando a partir de las diferentes miradas y formas de aproximarnos a ellas.
Por suerte, hoy día, tenemos un montón de herramientas que nos ayudan a llegar al proyecto mismo: control de versiones, visualización y filtrado de logs, monitorización de métricas, documentación, código fuente, comentarios, release notes, distintos entornos -de prueba, carga...- que nos hacen la vida más sencilla y nos permiten conocer los proyectos, su comportamiento y evolución ¿Quién ha cambiado qué? ¿Por qué lo ha hecho? Pero, claro, hay que tirarse al barro, remangarse, ponerse a probar, observar, recabar información... En fin, adoptar una actitud fenomenológica.
Mucho ir a la cosa misma, enfangarse y todo eso... pero hasta ahora lo único que hemos hecho ha sido idealizar nuestro proyecto: tratando de formarnos una idea más precisa de cómo funciona y, en fin, de lo que el proyecto es. Empezamos siendo críticos con el conocimiento teórico y acabamos volviendo a él. Pero en el camino ha ocurrido que nuestro conocimiento ha cambiado: es más profundo y detallado. Y podríamos perdernos en esa espiral virtuosa de conocimiento, pero el tiempo apremia y, realmente, no miramos el proyecto porque queramos adquirir conocimiento y tener una idea clara del mismo -un poco también es eso, pero no es lo más importante-, lo miramos desde nuestra circunstancia como desarrolladores, con una cierta intencionalidad: resolver el problema que nos bloquea el avance en nuestras tareas.
Heidegger fue alumno de Husserl pero consideró que su maestro había tomado un cierto rumbo idealista, que se había preocupado demasiado por el conocimiento, las ideas de las cosas y la relación entre ambas. Consideraba que había abandonado su propósito inicial: "ir a las cosas mismas". Heidegger dio un giro a la trayectoria de su maestro y se centró en el ser y en la existencia del individuo arrojado al mundo de la vida, llamó a esto "Dasain": ser ahí, estar en el mundo. Y eso es lo que nos ocurre a nosotros ante un problema: que estamos ahí, con nuestras circunstancias y, seguramente, no tenemos tiempo, permisos, ni recursos suficientes para llegar a tener una idea completa y fidedigna del proyecto y el entorno. Tenemos que partir de nuestra aproximación parcial, desde nuestro lugar en el mundo, compañía, equipo de trabajo...
En esta línea, Heidegger distinguió dos tipos de ser: un "ser a la mano" en el que no nos preocupamos mucho por cómo es la cosa en sí -por ejemplo, cuando tenemos nuestro ordenador y nuestro IDE funcionando como un reloj suizo, no nos importa cómo está ensamblado, simplemente los utilizamos-. Pero, cuando algo se rompe, o nos da problemas, entonces empezamos a preocuparnos por su ser: cómo funciona, de qué está hecho... Esta nueva preocupación por el ser es lo que Heiddeger llamó el "ser a la vista".
Ocurrió en nuestro equipo que, mientras hacíamos una actualización de dependencias de un proyecto, empezó a fallar el despliegue. Y era algo que no tenía mucho sentido, porque pasaba todos los tests, se ejecutaba en local... Pero, cuando intentábamos levantarlo en el entorno de desarrollo, se quedaba tostado. Nos tuvo bloqueados varias semanas. Era un proyecto del que sabíamos muy poco, y no había expertos a los que poder recurrir: varios equipos habían trabajado en él, pero todos tenían su conocimiento parcial. Finalmente, resultó que el cliente de mensajería de colas -Kafka-, había introducido algún cambio y hacía fallar un proceso interno que verificaba si se había llegado a leer todos los mensajes de la cola antes de dar la aplicación como healthy.
Así que, el problema, hizo que dejáramos de lado una serie de acciones que ya teníamos bastante sistematizadas para actualizar aplicaciones y nos puso el proyecto a la vista. Y, una vez visto, sentimos la necesidad de comprenderlo. Aunque no lo comprendimos del todo y no desentrañamos su ser. Porque somos personas pragmáticas, técnicas, ingeniosos ingenieros que cumplimos con los dead lines... así que asumimos nuestra circunstancia y conseguimos llegar, no a la mejor solución posible, sino a una solución de compromiso.
Al final, estos proyectos de software son construcciones humanas y, muchas veces, nos sentimos tentados de tirarlas a la basura y rehacerlas de nuevo. Porque, además, construir cosas nuevas es mucho más gratificante que no enredarse en estos problemas y estar durante semanas sin ver avances. Pero, a menudo, ocurre que la nueva implementación resuelve viejos problemas y genera otros. Cuesta mucho dejar algo funcionando fino, fino. Por eso a las IA y algoritmos hay que entrenarlos y los mejores profesionales son los que han aprendido haciendo. Seguramente andamos escasos de actitud fenomenológica: de ese ir a las cosas mismas. Y, en el caso de las construcciones humanas no dedicamos tiempo suficiente a comprenderlas, reapropiárnoslas o mejorarlas... Las descartamos rápidamente con el ávido deseo de implementar nuestras propias atractivas y dinámicas soluciones que resulten más rápidas, precisas y eficientes para nuestros fines. Al menos es así en el mundo de la tecnología y, porqué no decirlo, también en el de la ciencia. Pareciera que son áreas estas de conocimiento que se sostienen sobre la pura actualidad, como si no tuvieran historia -o como si esta fuera absolutamente prescindible-. Se sostienen sobre la idea de un positivismo sin fisuras: sólo es verdad lo último y los antiguos estaban equivocados porque carecían de nuestros conocimientos y herramientas.
Husserl y otros fenomenólogos fueron muy críticos con la racionalidad técnico-científica y su positivismo. Consideraban que habían evolucionado al servicio del sometimiento y la explotación -de la naturaleza y también de otros humanos-. Que en su loca carrera utilitarista, esta racionalidad, se ha olvidado de las circunstancias sociales que la hicieron posible y ha acabado reduciendo la realidad a su propia dimensión. Por ejemplo, si preguntamos ¿Qué es un altavoz? Nos vamos rápidamente a sus características técnicas o los conceptos científicos en que se basa su construcción. No decimos que es de donde sale la música, la voz de nuestros seres queridos, o lo molesto que resulta cuando está cascado... Y para cualquier cosa que intentemos definir siempre damos prioridad a su dimensión científica o técnica, aunque para nosotros sean las menos relevantes de todas.
Heidegger fue aún más duro en sus críticas con la racionalidad científico-técnica, considerando que la cultura occidental se había preocupado únicamente por las cosas y se había olvidado del ser. Sólo vemos cosas. Cómo estas nos pueden resultar útiles para someter y transformar. Hemos perdido la capacidad de maravillarnos al observar la realidad.
Quizá todas esas críticas se traslucen en la forma de afrontar los problemas que nos encontramos a la hora de desarrollar sobre productos ya hechos. Lejos de adoptar una actitud fenomenológica, o maravillarnos con las implementaciones de otros, abordamos los problemas con un cierto positivismo naif por el que creemos ser mejores solo por el hecho de estar por delante en la línea del tiempo.
Y, bueno, caminamos a hombros de gigantes -apoyándonos en lo que otros construyeron-. La fenomenología no cuestiona ese hecho, sólo nos dice que lo pongamos entre paréntesis, en suspenso; que revisemos y verifiquemos con la cosa misma -con nuestra experiencia de la cosa-. Es esa actitud, de conocimiento y maravillarse de lo ya existente, la que puede ayudarnos a solventar nuestros problemas tecnológicos y acercarnos a los que estuvieron ahí antes que nosotros. Comprendiéndolos, en lugar de desautorizarlos porque "Yo esto no lo entiendo, así que no debe tener sentido".
***********
No parece la fenomenología una corriente revolucionaria que pretenda dar la vuelta a la tortilla. Todo lo contrario, perece continuista de lo que hay, un profundizar en el Ser. Tampoco es revolucionario el mundo del desarrollo de aplicaciones -aunque en la época álgida del software libre fantaseáramos con su poder transformador-.
Estos filósofos vivieron tiempos convulsos en la Europa de entre guerras. A Heidegger su existencialimo no le salvó de afiliarse al partido nazi. También los programadores nos embarcamos en empresas inmorales -aplicaciones adictivas, de control...- . Pero, otros autores, como Lévinas, confirieron una dimensión ética a la fenomenología. Resaltando su carácter intersubjetivo, la construcción social de las ideas y el reconocimiento del otro como otro yo. Y es, quizá, ese vernos reflejados en los otros, reconocer su trabajo y subjetividad, lo que nos permita salir de esta deriva tan antihumana -de guerras, consumo y desigualdad- en la que andamos embarcados.
