Una personalidad controladora sufre si las cosas no salen como quiere. Si le salen bien, sufren los demás. Así, sin quererlo, se me ha ocurrido una metáfora para ilustrar este tipo de comportamiento: el código espagueti emocional.
Sin comerlo ni beberlo, un buen día me tocó adoptar un código salvaje de varios miles de líneas, escasos métodos y una nomenclatura de variables despiadada. Hace lo que quiere, a su manera y sin avisar. Cada vez que lo saco de su jaula, antes de ejecutarlo, me cercioro de que el resto de sistemas estén a salvo, detrás de un amplio perímetro de seguridad.
Por si solo, el animal engulle, analiza y escupe millones de registros. Mientras no tenga un mal día, es eficaz en su propósito. Requiere su tiempo, pero cumple con las órdenes. Ahora bien, si el mínimo imprevisto se interpone en su camino, ya no hay quien le haga entrar en razón. ¿Qué te ha pasado? ¿A qué viene tanto drama? ¿Y qué significa esta retahíla de improperios en blanco sobre negro?
La teoría recomienda modular, desacoplar y simplificar en la medida de lo posible. La finalidad es adiestrar un código fácil de mantener, dejar un legado dócil por así decir. Nuestro archivo, inexpugnable en sus intenciones, no permite que lo testeen, y menos aun que le cambien el nombre de sus variables, el muy porfiado utiliza, una y otra vez, los mismos nombres —enigmáticos todos ellos— para representar cosas bien distintas. Por ejemplo, lsdaut podría ser el nombre de una lista de coches en un momento dado, para convertirse, un centenar de líneas más abajo, en un listado de partes de una lavadora. Cambiar cualquier parte del código puede provocar comportamientos exóticos, respaldando aquel adagio que reza que, la nuestra, es la única ingeniería en la que si apagas la luz del salón corres el riesgo de que se active la cadena del váter del vecino.
Ahora, ¿qué tiene que ver este código rebelde con una persona controladora? Pues resulta que nuestro archivo salvaje es, precisamente, un espécimen de personalidad rígida hecha código fuente: le aterran los cambios, se aferra a sus costumbres y, ante la menor variación del entorno, colapsa en un despliegue dramático digno de un adolescente etiquetado en una foto antigua disfrazado de su ex ídolo infantil.
Ambos, humanos controladores y código rígido, comparten un miedo irracional a lo inesperado. Y ambos reaccionan exactamente igual ante un pequeño imprevisto: colapsando, protestando o lanzando excepciones con mensajes incomprensibles. Un programador veterano sabe que es más fácil enseñarle lógica booleana a una cabra, que razonar con un bloque de código monolítico cuando está de malas.
Tanto en psicología como en programación, intentar controlar demasiado produce justo lo contrario: pérdida total del control. Cuando escribes código demasiado acoplado, estás diciendo: «o se hace a mi manera o no se hace». El problema es que en la vida real —y en producción— las cosas rara vez salen exactamente a tu manera. Así que cuando eso sucede, tu código controlador simplemente deja de hablarte, te banea y se va de vacaciones dejando un rastro de registros para que te acuerdes de él día y noche.
Al igual que algunos desarrolladores creen que un archivo gigante y todopoderoso es más fácil de controlar, ciertas personas piensan que si gestionan cada detalle de la vida o de un proyecto estarán más seguros. El resultado es que todo equipo liderado por estas personalidades termina siendo un legado difícil de mantener emocionalmente: nadie entiende las decisiones, todos dependen de un solo punto central, y cada cambio produce consecuencias inesperadas y generalmente dramáticas.
La solución es la misma para ambos mundos. Así como la programación recomienda refactorizar, desacoplar y aplicar patrones de diseño saludables para reducir el estrés del mantenimiento, la psicología recomienda flexibilizar, ceder el control y aceptar la incertidumbre como parte natural de la vida.
¿Qué podemos hacer? Igual que nadie aconseja «tirar todo a la basura y empezar de cero» (salvo ese compañero junior de osado entusiasmo), tampoco podemos simplemente cambiar nuestra personalidad de la noche a la mañana. Ambas tareas son lentas, costosas y propensas a recaídas. La estrategia correcta pasa por pasos pequeños pero constantes: modular nuestra conducta, definir claramente responsabilidades (métodos y variables), y renombrar nuestras obsesiones con nombres comprensibles, cercanos a la realidad. Es decir, asumir que lsdaut es una pésima forma de llamar a una lista, tanto como es pésimo decirte a ti misma que eres un fracasada por no haber conseguido lo que querías.
Al final, la programación nos recuerda que no se puede controlar todo. Ni siquiera tu propio código, por mucho testeo unitario que le apliques. La vida real (y también el usuario final) siempre encontrará la manera de sorprendernos. Ante eso, lo mejor que podemos hacer es dejar atrás el código espagueti emocional, aceptar que a veces el nombre de una variable puede y debe cambiarse, y entender que si tu sistema no puede soportar el cambio, quizá el problema no esté en los requisitos, sino en tu actitud ante ellos.