Inventar un Paralex

¿Sabíais que el Paralex lo inventó un arquitecto? Es una historia extrañamente desconocida y poco documentada: aunque ya existían herramientas parecidas, el DIN-Graph o Paralex, tal y como lo conocemos en España —para los nativos digitales: una regla plana con poleas fijadas encima y dos hilos cruzados sujetos a la mesa—, lo inventó a finales de los años cuarenta un tal Francisco Enrique Gómez de Puig, por aquel entonces aún estudiante de arquitectura. Francisco se fijó en un armatoste que había traído un compañero de algún lugar de Europa central, se planteó mejorarlo, y tras varios prototipos llegó a un dispositivo sencillo, ligero y asombrosamente eficaz que muchos dimos por amortizado en el primer día de uso.

¿Qué hay de maravilloso en este acto de invención? ¿Por qué es relevante que viniera de un arquitecto y no un empresario o un inventor generalista? Precisamente porque se trata de un fenómeno habitual al que no prestamos demasiada atención: lo que Francisco hizo fue desarrollar su propia herramienta para resolver un problema que conocía de primera mano. Algo que toda profesión viene haciendo desde que alguien intentó tallar una piedra golpeándola con otra, pero que tendemos a olvidar en favor de grandes soluciones de empresas cada vez más enormes y remotas.

Seguro que todos podemos recordar fácilmente ejemplos más o menos actuales de esa «inventiva en proximidad». Viejos scripts de Autocad 14 que permitían, por ejemplo, gestionar capas de forma mucho más rápida y potente. Hojas de cálculo que permitían hacer presupuestos o resolver problemas de cálculo estructural. Sketches de Processing más allá de Orión. Scripts de Grasshopper brillando en la oscuridad…

También apostaría a que la gran mayoría hemos creado cosas así alguna vez. Seguramente buscando resolver un problema, y, probablemente, descubriendo sin querer un proceso enormemente didáctico y empoderante que nos permite unir a nuestra manera el qué hacemos con el cómo lo hacemos. Y si me decís que no es así… entonces tenemos un problema de dependencia y subdesarrollo profesional, porque hacer nuestras propias herramientas siempre tuvo sentido, y lo tiene ahora más que nunca.

Con la facilidad que tenemos de acceso a recursos y conocimientos; con la cantidad de herramientas en las que nos podemos apoyar para desarrollar las nuestras; con nuestra propia dispersión desde la arquitectura hacia otros campos como la programación; con el auge del diseño paramétrico o la arquitectura informacional y la existencia de plataformas que favorecen el desarrollo de herramientas a medida; con todo esto es casi injustificable que nos apoyemos exclusivamente en soluciones prediseñadas.

Es rascándonos nuestro propio picor como podemos desarrollar herramientas hiper-específicas que apenas tienen mercado para grandes empresas pero que nos resultan de gran utilidad. Y cuando digo «herramientas» generalmente hablo de utilidades, pequeñas automatizaciones o ayudas a nuestro trabajo, pero con un poco de organización se pueden llevar a un nivel más alto de complejidad.

Lo más interesante es que resolviendo problemas propios podemos resolver los de otras personas, compañeras de profesión o de actividad. Se abre todo un mundo de posibilidades si reconocemos el valor de estos desarrollos y los compartimos. En un próximo post sugeriré algunas vías para lograrlo, pero por ahora me voy a quedar en una sencilla reivindicación:

¿Y si empezamos a favorecer y visibilizar la solución propia, cercana? ¿Por qué delegar siempre —como hacemos a diario desde nuestras instituciones, desde la educación, o con nuestro dinero y uso activo— el desarrollo de nuestras herramientas a quienes nos van a vender caros y enormes sistemas cuando, quizás, sólo necesitábamos inventar un Paralex?