Porque el informático actual pretende ser, también, el solitario que, de nuevo, mata al Dios insoportable que mediatiza su pasmo creativo. Así el programador -el “creador más feo”, en definitiva- trata de imponer su esfuerzo eminentemente personal sobre la maraña tecnológica en que su profesión se apoya, intentando despuntar en la composición creativa; queriendo sustanciar su necesaria condición protagonista. Y Dios queda de nuevo muerto, doblemente. ¡Ah!, pero los tiempos han cambiado: la composición software se da ahora por módulos, por paquetes, por objetos; y las posibilidades de encontrar el nicho genial, la solución pasmosa, disminuyen y casi desaparecen, en favor de formidables monitores: modelos de componentes, patrones y frameworks. El programador se encuentra, así, en un universo de interoperabilidad deseada, en el que los sistemas software se crean extendiendo y combinando productos pre-existentes, lo que supone que el pasmo “creativo” ha de trocarse en “colaborativo”, pues el modelo de componentes secuestra a los lenguajes de programación (normas de codificación, de identificadores, de modularidad ineludible, de conducta social[1]); los patrones necesitan del consenso en la experiencia (para publicarse requieren de su identificación en al menos tres grandes sistemas); y los frameworks, como las autopistas, saben de velocidad, pero a la vez fuerzan el destino, y uno siente como si le inocularan, a modo de eutanasia, un sedante/veneno que le acerca –rápido, eso sí- a la muerte. Los mismos entornos de programación han cambiado sustancialmente, pues pretenden operar con componentes software transportables a otros entornos de la competencia, de forma que su ventaja estratégica competitiva pasa a basarse en la asunción de “arquitecturas[2]” (de integración, de acceso a bases de datos, etc.) y, de nuevo, en la prestación de “patrones colaborativos de objetos” (componentes interrelacionados en modelos de roles). Resulta, así, que el programador ya no se sabe solo, y su buscada sociopatía –debida mayormente a la indefinición de su propia profesión- ha de convertirse en amago de educación/camaradería: con el lenguaje de programación, con el código de otros, con su familia. Claro que alguno se rebela, y pretende apoyarse en la vacua difuminación tecnológica para sustanciar su discutible remuneración y su indefinible trabajo, convirtiendo en lugar común lo que yo denominaría “abstrusismo software”. Y es que, ¡ay!, el programador ha pasado de querer estar solo a quedar compuesto y sin dios: de nuevo solo, pero preparado para no estarlo.

[1] A quien enseñe el lenguaje de programación Java sin tener en cuenta el JDK entero habría que cortarle, al menos, una pierna. De nada sirve Java sin asumir, verbigracia, los APIs de JavaBeans. De nada sirve el genio si nuestros módulos Java son rechazados (por solitarios, por incomprensibles) en continentes de Jcode. De nada sirve Java.

[2] Cuando se habla de “arquitectura software”, ¿de qué demonios se está hablando? Oh, sí, el Software Engineering Institute (SEI) procura definiciones, pero son demasiadas, demasiado distanciadas. El título, sin embargo, resulta aparente y troca patente, otra vez, las inseguridades de la profesión informática.