El lienzo

In some ways, programming is like painting. You start with a blank canvas and certain basic raw materials. You use a combination of science, art, and craft to determine what to do with them.

— The Pragmatic Programmer, D. Thomas & A. Hunt

Thomas y Hunt escribían esto en 1999, y la comparación ha envejecido lo bastante bien como para circular ya sin atribución, que es el destino habitual de una buena analogía. Merece la pena detenerse en ella, porque las tres palabras que usan —ciencia, arte, oficio— no son decorativas. Son una afirmación sobre qué clase de actividad es esta, y la afirmación resulta más incómoda de lo que parece.

La ciencia es la parte con la que todo el mundo está cómodo. Hay invariantes, clases de complejidad, sistemas de tipos, cosas que son verdad crea el equipo lo que crea. El arte es la parte que a todo el mundo le gusta invocar en las charlas. El oficio es la parte que nadie quiere pagar.

El material que no ofrece resistencia

Un pintor trabaja contra un material. El pigmento seca a su propia velocidad, el lienzo absorbe lo que absorbe, la gravedad tiene opiniones sobre una superficie húmeda. David Pye llamó a esto el workmanship of risk: el resultado no está predeterminado por el plan, se va determinando de forma continua por la mano y por el material empujando de vuelta.

El software apenas tiene resistencia material. Nada seca. Nada se descuelga. No hay veta con la que trabajar ni contra la que trabajar. Esto suena a ventaja y es el origen de casi todos los problemas, porque toda restricción en un sistema de software es una restricción que alguien eligió. Donde el carpintero puede culpar a la madera, nosotros solo podemos culpar a una decisión que tomamos hace tres trimestres y de la que ya no nos acordamos.

Por eso la parte de oficio importa aquí más que en los trabajos donde el material se encarga de una parte de la disciplina. Cuando el medio no impone nada, la disciplina hay que importarla.

Lo que la pintura esconde

La analogía se rompe en un punto concreto, y la rotura es instructiva. Un cuadro se termina. Alguien decide que la última pincelada ya ha ocurrido, se barniza, se cuelga en una pared, y desde ese momento su trabajo consiste en ser mirado.

Los productos digitales no se barnizan nunca. Peter Naur sostenía que un programa no es en realidad el texto del programa, sino una teoría sostenida por las personas que lo escribieron: una teoría sobre el dominio y sobre por qué el código tiene la forma que tiene. El texto es el residuo. Cuando esas personas se van, la teoría se va con ellas, y lo que queda atrás es un lienzo cuyas pinceladas ya nadie sabe explicar.

Es un artefacto extraño. Parece terminado y se comporta como un rumor.

También significa que el lienzo en blanco es casi siempre una ficción. Muy pocos equipos empiezan de cero. Heredan una base de código, un proveedor de pagos del que no pueden salir, un modelo de datos con la forma de un mercado al que ya no sirven, y unos cuantos miles de usuarios con hábitos. La habilidad de verdad no consiste en decidir qué poner en una superficie vacía. Consiste en decidir qué hacer con una superficie sobre la que ya han trabajado tres pintores anteriores, ninguno de los cuales dejó anotaciones. Christopher Alexander dedicó su carrera exactamente a este problema —cómo se selecciona la forma bajo restricciones que no has puesto tú— y llegó a conclusiones bastante menos alegres de lo que sugiere una metáfora sobre lienzos vacíos.

Donde la analogía se gana el sueldo

Con todo, vuelvo a ella por una razón: acierta con la dirección de la causalidad.

El automatismo organizativo consiste en tratar la construcción como ejecución. Decidir y luego construir. El plan es donde vive el pensamiento y la construcción es donde el pensamiento se pasa a limpio. Cualquiera que haya pintado algo sabe que es al revés. Descubres cuál es el cuadro pintándolo. Descubres que la composición estaba mal justo en el punto en el que ya has comprometido suficiente pintura como para que el descubrimiento salga caro.

Brooks hizo la misma observación con menos encanto y más evidencia: la parte difícil no es escribir el código, es llegar a la concepción, y la concepción no deja de cambiar porque construirla es lo que te enseña sobre ella. Que es la razón por la que los productos basados en software son tan difíciles: no porque teclear sea complicado, sino porque el aprender y el comprometerse ocurren en el mismo gesto.

La versión del oficio que ofrece Richard Sennett es útil aquí porque se niega a la lectura romántica. El artesano no es un espíritu libre. El artesano es alguien que ha pasado tiempo suficiente con un material como para haberse ganado un juicio sobre él, y ese juicio es lo único que separa un plan de un desastre.

Hay una versión barata de esta analogía en la que el trabajo de producto se convierte en expresión personal, la hoja de ruta se convierte en lienzo, y todo el mundo puede llamarse artista. Conviene resistirse a esa lectura. No pintas para ti. Alguien tiene que vivir dentro de lo que haces, usarlo una mañana mala y pagarlo. El lienzo es suyo.