Tal y como he explicado en la serie Cuadernos de Bitácora, durante los últimos años me he sumergido de lleno en el aprendizaje de la programación y del desarrollo de herramientas informáticas diseñadas específicamente para asistir en el ejercicio de la labor jurisdiccional.
No soy, ni de lejos, un experto en la materia, pero lo cierto es que lo largo de este período he aprendido que existe una brecha enorme entre escribir líneas de código y construir soluciones reales.
Ese abismo que separa la escritura de código de la creación de una solución real no es una simple percepción personal sino que constituye una disciplina técnica y teórica en sí misma. En el sector tecnológico, este terreno abarca desde la Ingeniería de Software al Diseño de Producto, áreas que se encargan de que la tecnología sea un medio perfectamente alineado con las necesidades del mundo real.
Precisamente de mi experiencia particular sale esta entrada, cuyo objeto no es otro que diseccionar ese espacio intermedio, analizando los errores estructurales que cometí al ignorar que un programa es un organismo vivo que requiere arquitectura y método.
Soy consciente de que lo que aquí expongo son lecciones que para un programador profesional resultarán baladíes, pero que yo he tenido que aprender bajo mi propio riesgo y ventura. Cada una de estas verdades, evidentes para el experto, ha sido para mí una conquista personal tras enfrentarme al ensayo y error de un aprendizaje puramente autodidacta.
Con tal de llevar a cabo tal exposición, he decidido estructurar esta experiencia en dos entradas diferenciadas: una entrada centrado en mi experiencia creando interfaces visuales y otra apartado basado en las correcciones que he tenido que ir aplicando a mi código.
Así pues, en esta primera publicación vamos a abordar una serie de reflexiones sobre pequeños aspectos que he ido aprendiendo a la hora de crear programas informáticos aplicados a justicia, centrándonos en lo que al algoritmo, al flujo de usuario y a la interfaz se refiere.
A) De los proyectos personales al uso generalizado
Mis inicios en el mundo de la programación se centraron en crear herramientas que iban a ser usadas exclusivamente para mí, lo cual se encuentra a años luz del desarrollo de programas destinados a ser abiertos al resto de compañeros.
Cuando el proceso empieza y termina en mi propio ordenador, uno se encuentra con la tranquilidad de que la herramienta únicamente tiene que ser capaz de contener mi criterio y mi forma de hacer, es decir, un reflejo de mi propia estructura mental.
Sin embargo, al crear herramientas con vocación de ser compartidas, el paradigma es radicalmente diferente: hay que ser mucho más abierto a las distintas formas de procesar la información que puedan tener personas con esquemas mentales distintos al mío, y realizar un esfuerzo consciente para que la herramienta sea lo más global posible.
El reto reside en conseguir que el software sea capaz de integrarse con naturalidad en el mayor número de metodologías de trabajo posibles, permitiendo que cada usuario encuentre su espacio sin que mi propia lógica le resulte una imposición, porque de lo contrario la gran mayoría de los usuarios se descolgarían de su uso al no adaptarse o no encajar netamente en su forma de actuar.
Pongamos un ejemplo práctico y concreto para ilustrar esta idea. En mi entrada Mas allá de la teoría: un recorrido por mi ecosistema hice una relación de las distintas herramientas que he creado y que uso a diario. Una de ellas es el asistente para el dictado de autos de prisión, la cual es una herramienta que empieza y acaba en mi ordenador, pues no fue creada con ánimo de ser usada por terceros. La herramienta no está preparada ni para cambiar el juzgado o plaza que preside el encabezamiento de toda resolución judicial, y comprende única y exclusivamente los argumentos y fundamentos que yo le he introducido, sin permitir su edición.
Una vez que somos conscientes de que la creación de herramientas para uso general exige un desarrollo mucho más meticuloso y una amplitud de miras superior al uso particular, surge otro punto esencial que quiero tocar: el conocimiento sobre la materia.
B) De los cimientos
En la administración pública, y especialmente en la administración de justicia, disponemos con demasiada frecuencia de herramientas que se caracterizan por ser profundamente ilógicas. Estamos acostumbrados a utilizar softwares que si bien podríamos catalogar como "eficaces" por cuanto cumplen con su labor, son profundamente ineficientes, pues la estructura que los rige no acaba de encajar netamente en el día a día de los juzgados.
Ello es, en cierta medida, normal, pues son aplicaciones desarrolladas por personas que claramente no están detrás de la labor jurisdiccional diaria. Es muy probable que hayan contado con asesores durante el proceso, pero si el desarrollo de una herramienta se enfoca desde una premisa o una base equivocada, el resultado está condenado.
Esta desconexión entre el desarrollador y el usuario final no es un problema estético, sino de cimientos: al construir código, se toman decisiones estructurales que actúan como muros de carga que si se levantan sobre una premisa errónea, no se pueden corregir con parches superficiales, pues forman parte del núcleo esencial del software. Cambiarlas a posteriori no es posible pues no se trata de una simple actualización, sino de una refactorización en toda regla.
Un ejemplo personal y muy concreto de esto ocurrió con el régimen de suspensión en mi herramienta de conformidades. En mi primera versión particular, tomé la decisión de crear un único apartado de suspensión para todas las penas. Estructuralmente, el programa asumía que el destino de cada condena era unitario. Sin embargo, la realidad jurisdiccional es mucho más compleja: un acusado puede ser condenado por dos delitos que lleven aparejadas penas de prisión y que para uno quepa la suspensión ordinaria y para el otro no, o que uno deba tramitarse por el artículo 80.3 y otro por el 80.5 del Código Penal.
Cuando me percaté del error, ya era demasiado tarde. El código era tan rígido que aplicar ese cambio habría exigido una versión 2.0 con una interfaz completamente distinta, preparada para albergar una lógica que tiene un impacto visual y funcional inmenso, por no hablar de la transformación profunda del sistema de gestión de variables que incorporaba el programa.
Por eso, en la herramienta que desarrollamos junto con Picasso, optamos desde el inicio por una base sólida: una interfaz que permite al usuario crear tantos pronunciamientos como sean necesarios, agrupando o separando las penas a su antojo.
Esta realidad nos lleva a una conclusión inevitable: la fase de diseño y desarrollo de cualquier software judicial debe estar dirigida, o al menos profundamente supervisada, por personas capaces de entender tanto la profundidad jurídica de cada decisión como la lógica del código que lo rige. No basta con saber programar ni con saber de derecho: hay que comprender las instituciones que se están tratando y ser capaz de proyectar el algoritmo que regirá a la aplicación.
Cuántas veces compañeros de jurisdicciones distintas a la penal me han pedido crear una herramienta para asistirles en el dictado de un determinado tipo de resolución y mi respuesta siempre es la misma: no es tan sencillo. Necesitaría pasar semanas sumergido en el día a día de esa jurisdicción concreta y mantener infinidad de contactos con quienes la operan para llegar a hacer un simple esbozo de cómo proyectar tanto la interfaz como la arquitectura de la herramienta.
Yo soy juez de lo penal y entiendo (ligeramente) qué debe contener y cómo debe fluir un programa aplicado a mi campo, pero el resto, de momento, se me escapan. Por eso, con demasiada frecuencia y como ocurre actualmente, vemos programas que han sido diseñados claramente para una jurisdicción específica, generalmente la civil, y que luego se intentan extrapolar al resto. El resultado, como cabe esperar cuando se ignora la naturaleza propia de cada rito procesal, es un resultado más que cuestionable.
Es algo que sufrimos a diario: se ponen a nuestra disposición herramientas que no atinan, que rascan solo la superficie del problema o que, en el peor de los casos, están manifiestamente mal enfocadas desde su génesis.
Cuando el arquitecto del sistema ignora los matices del derecho o la idiosincrasia propia de cada jurisdicción, el resultado es una herramienta que, lejos de ser un aliado, se convierte en una carga que nos obliga a adaptar el derecho a la limitación del software, cuando debería ser exactamente al revés.
C) De la ergonomía
La herramienta tiene que ser, por encima de todo, ergonómica. Es inconcebible que el ratón tenga que estar dando vueltas por la pantalla, como si se tratara de un Ulises moderno intentando volver de la guerra de Troya, y ello solo para completar una tarea sencilla.
A su vez, es inasumible que nos encontremos con una sucesión ilógica de clics para resolver cuestiones que deberían despacharse con un único desplegable o una sola acción directa. Del mismo modo, es inadmisible que la información esencial esté repartida de forma antinatural en apartados o pestañas distintas, obligando al usuario a saltar de un sitio a otro sin una lógica procesal clara.
Es cierto que en el desarrollo de la interfaz en ocasiones hay que tomar decisiones que no siempre van a ser las mejores, pero esto ocurre porque a veces el objeto sobre el que recaen es tan peculiar o tan específico que resulta muy difícil encontrar un punto intermedio.
Esto es algo que he vivido en múltiples sesiones con Picasso, donde discrepábamos sobre cómo exhibir la información o incluso sobre qué información concreta debía exhibirse y en qué momento preciso.
Sin embargo, como la base era sólida y se trataba de una herramienta que se nota a la legua que ha sido creada por y para jueces, pese a tomar esas decisiones que podrían catalogarse como controvertidas desde una perspectiva de la estructura de la herramienta, el resultado final seguía siendo idóneo.
Al final, cuando el cimiento es el correcto, la herramienta sobrevive a sus propias dudas de diseño porque la lógica que la sustenta es la que el profesional necesita.
En definitiva, la interfaz no es un simple envoltorio estético, sino la materialización de un flujo de trabajo. Una herramienta judicial bien diseñada debe ser capaz de pasar desapercibida, permitiendo que el juez se centre en la toma de decisiones y no en la gestión del programa.
Cuando logramos que la tecnología se pliegue a la metodología jurídica y no al revés, eliminando el ruido y el movimiento innecesario, estamos respetando lo más valioso que tiene un profesional en su día a día: su tiempo y su capacidad de análisis.
Conclusión
Entender el derecho no es suficiente para digitalizarlo, y saber programar no es suficiente para modernizar un juzgado. La clave reside en habitar ese espacio intermedio, ese abismo del que hablaba al principio, donde la precisión del algoritmo se rinde ante la flexibilidad y la independencia que exige nuestra función.
Solo cuando el diseñador del software es capaz de comprender los cimientos jurídicos, y el jurista logra entender la arquitectura interna de un programa, surge esa cohesión entre ambos extremos que es la que verdaderamente define la calidad de una herramienta.
Es precisamente en esa hermandad entre el código y el derecho donde la tecnología deja de ser un obstáculo para convertirse en el puente que nos permite dedicarnos a nuestra esencia, que no es otra que resolver los problemas de la gente.
Como cierre de esta primera parte, cabe destacar que en estas líneas me he limitado a diseccionar los aspectos más fundacionales: desde la concepción del diseño hasta el user flow y la interfaz. Sin embargo, esto es solo la superficie de lo que implica construir una herramienta robusta.
En la próxima entrega, nos sumergiremos de lleno en las tripas del sistema para hablar de código puro, abordando conceptos como la escalabilidad, la modularización y la importancia crítica del testeo, junto a otras tantas lecciones técnicas que he ido asimilando a base de enfrentarme a mis propios errores de desarrollo.
0 Comentarios