Soy un apasionado de la filosofía, y también el desarrollo de software. Así que, de vez en cuando, se me presentan puntos de intersección en los que ambas disciplinas se dan la mano. La fenomenología es una corriente filosófica dura y densa pero, aterrizarla en nuestros problemas tecnológicos cotidianos, puede regalarnos algunas ideas y formas de hacer que podrían resultarnos útiles -incluso motivadoras-.
La fenomenología es seguramente una de las corrientes filosóficas occidentales más importantes e influyentes del último siglo. Sus principales autores fueron: Husserl -al que puede considerarse el padre de este movimiento-, Heidegger, Merleau-Ponty, Sartre, Gadamer… Con el estallido de la Segunda Guerra Mundial, algunos de estos filósofos abandonaron el viejo continente y la fenomenología extendió su influencia por las Américas. Así que, hoy día, existe una extensa bibliografía y numerosos expertos que continúan profundizando y transformando esta corriente filosófica, y no sólo en la lengua alemana o francesa, sino también en inglés y español.
¿Y qué puede tener que ver la filosofía con la resolución de problemas -especialmente de problemas tecnológicos-? Bueno… no es sólo un título que busca generar expectación. En este post intentaré compartir mi experiencia de: cómo mantener una actitud fenomenológica puede ser útil a la hora de abordar ciertos problemas que surgen en el desarrollo de software. Quizá no sea un remedio milagroso pero, al menos, nos hará sentir parte de un área de conocimiento más amplia y conectará nuestras miserias como desarrolladores con los grandes problemas de la humanidad: ¿Qué es el Ser? ¿Es posible el conocimiento? Quizás, de esta manera, nos ayude a ir más allá, nos dé una bombona de oxígeno para profundizar y, finalmente, nos conduzca al éxito -si abordamos el problema como una cuestión trascendental y no como un simple problema técnico-.
El conocimiento teórico
Si pudiéramos definir la fenomenología en una sola frase diríamos con Husserl que: hay que «ir a las cosas mismas«. Y, la cosa misma, 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 acumulación y acaparamiento de 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 algunas compañías, la forma de promocionar consiste en defender ante un comité de «expertos» que manejas una buena retahíla de conocimientos teóricos. Y, muchas entrevistas de trabajo, acaban convirtiéndose en un enumerar tecnologías, saber situarlas en un cierto espectro de negocio -y esperar que coincidan con la checklist del entrevistador-.
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. Pero seamos realistas: en la era del internet y las IA, el saber enciclopédico ha perdido fuerza frente a otras habilidades como pueden ser buscar, filtrar y contrastar información, modelar o aprender haciendo… Ya no es tan fácil salir airosos de tirarse el pegote fingiendo que se sabe de algo -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-.
Vayamos más allá de la subjetividad!
Al final, la fenomenología va de aportar certezas, 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.
Heidegger
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» [Zuhandenheit] 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» [Vorhandenheit].
El problema hace su aparición
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.
La racionalidad científico-técnica
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 desde nuestra propia experiencia. Pareciera que en el mundo de la ciencia y la tecnología no hay historia, como si se sostuvieran sobre la más pura actualidad, sobre un positivismo sin fisuras: sólo es verdad lo último y los antiguos estaban equivocados porque carecían de nuestros conocimientos y herramientas.
La fenomenología fue muy crítica con esta actitud técnico-científica y su positivismo casi naif. 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 había olvidado de las circunstancias sociales que la hicieron posible y había acabado reduciendo la realidad a su propia dimensión de exactitud, eficiencia, predicibilidad, rapidez, utilidad, idealidad… Y cuando aparece el problema tendemos a abordarlo desde ahí:
Tecno-Ciencia dice: -«Kafka es una plataforma de distribucion de eventos…»
Pero Fenomenología dice: -«Sí, sí, muy bien. Pero ¿Qué es Kafka en nuestro proyecto? ¿Para qué lo estamos usando? ¿Nos sentimos cómodos con él? ¿Qué necesidad hizo que se incluyera?…«.
Abordar la realidad desde lo que se nos da. Esa es la actitud que nos puede hacer maravillarnos ante la brillantez de la implementación, comprender nuestro Kafka, no desde la definición en una página web, sino, desde la realidad de su uso y, quizá, afrontar los problemas que surjan con cierta garantía de éxito.
