Programs must be written for people to read,

and only incidentally for machines to execute.

Harold Abelson

Desde que empecé a escribir textos (de ficción o no ficción), lo hago como si estuviera escribiendo un programa de computadoras. ¿Qué significa esto? Voy a intentar explicarlo.

La forma en la que escribo programas (o funciones, o tareas, o features, o subsistemas) suele ser siempre la misma: ensayo una primera versión, preliminar, que no hace todo lo que va a hacer la versión final, pero que va de inicio a fin o al menos de un inicio a un final, y desde ahí avanzo. Veamos un ejemplo. Si la descripción del trabajo por realizar es “agregar un nuevo comando que liste los usuarios en la base de datos”, yo escribo la mínima cantidad de código necesario para que luego de mi intervención, en el sistema haya un nuevo comando y cuando este se ejecute muestre algo en pantalla. Esa es mi versión 0.1. Después me preocuparé por refinarla, es decir, por conectarme a la base de datos, por obtener la lista de usuarios y por mostrarlos con el formato requerido.

La metodología descripta podría denominarse “prototipado evolutivo”: se escribe un primer prototipo para la solución y este evoluciona en las distintas iteraciones. Cada iteración puede, por ejemplo, terminar en una reunión con el cliente para mostrarle el estado actual y, a partir de su feedback, ajustar, corregir y mejorar el programa. También podría decirse que es un desarrollo de tipo top-down, en el que se hace un diseño general y luego se van completando los detalles de implementación. En contraposición con el denominado bottom-up, en el que primero se implementan los elementos fundamentales y a continuación se construye “hacia arriba”.

Cuando escribo textos de ficción o artículos como este, intento aplicar el mismo procedimiento. El primer paso es conseguir una versión no acabada, pero sí completa: llegar a la última oración. Más tarde empieza el refinamiento. Tomo estos dos adjetivos del prólogo a Los sinsabores del verdadero policía del crítico Juan Antonio Masoliver Ródenas en el que señala que, como 2666, esta es “una novela inacabada, pero no una novela incompleta”.

En un programa, cada ejecución permite potencialmente encontrar bugs (errores). ¿Cuál es el equivalente literario a la ejecución de un programa? Su lectura. Cada vez que alguien (el autor u otra persona) lee el texto puede encontrar errores: comas mal puestas, ripios (descubrirlos requiere la lectura en voz alta), palabras mal escritas, palabras mal usadas, oraciones muy largas (otra vez, para esto la lectura en voz alta es fundamental), verbos mal conjugados o, los más difíciles de detectar, incongruencias. Estos últimos son los que en ingeniería de software se denominan “errores de la lógica del negocio”; no es que la aplicación explote cuando el usuario realiza determinada acción, sino que se comporta de forma inesperada. Por ejemplo, dos usuarios realizan transferencias bancarias en forma simultánea a una misma cuenta destino y solo una de las transferencias es contabilizada. El ejemplo literario sería que un personaje deja un arma en su casa y luego la usa en la calle para matar a alguien. Ambos ejemplos son exagerados a propósito.

Si una forma de encontrar errores en un programa es ejecutándolo, podemos decir que, estadísticamente, mientras más veces se lo ejecute, más errores se encontrarán. ¿Cómo logramos, entonces, tener más ejecuciones? En el mundo del open source, el modelo de desarrollo tipo “bazar” (impuesto por Linus Torvalds, creador del kernel Linux), en el que hay muchas personas que colaboran en un entorno abierto, significó un avance respecto a la metodología “catedral”, en la que un grupo de iluminados se encerraba a trabajar hasta que tenía el producto acabado. La filosofía del bazar pregona “release early, release often”, es decir, liberar versiones temprano y hacerlo a menudo. Esto permite que los errores se encuentren antes, el ciclo de desarrollo se retroalimente y las fallas puedan ser arregladas con rapidez.

¿Cuál es la versión en la escritura de la práctica anterior? Subir textos a internet para que otros los comenten, compartir el documento fuente en un formato que facilite las sugerencias, publicar en la prensa textos que después terminarán en un libro. Las tres formas mencionadas tienen distinto grado de apertura, por lo general, inversamente proporcional a la retroalimentación que se recibirá.

¿Podemos encontrar más puntos de contacto entre programación y escritura? Estoy seguro de que sí (la definición de variables tradicionalmente al principio de un bloque de código se asemeja a las pistas que debe sembrar un escritor de policiales; las tramas de las novelas pueden representarse con diagramas de flujos igual que como se hace con los algoritmos; las referencias a nombres no definidos pueden interrumpir tanto una lectura como una compilación), pero ya que una de las máximas de la ingeniería de software dice que un programa nunca se termina de escribir y una de las de la escritura es que el ensayo se puede terminar en cualquier momento, pongo punto final y subo este texto a internet.