El escritor argentino, Ricardo Piglia, tenía una máxima a la hora de escribir cuentos: «El cuento siempre cuenta dos historias; el cuento es un relato que encierra un relato secreto, que es la clave de la historia». Esto me hizo pensar en que la programación pasa similar, aunque sin el glamour de la literatura. Al programar, intentamos resolver problemas. Algunos tienen esa intención; otros sólo hacen lo que pueden, que rara vez, o casi nunca, coincide con ese objetivo. Sé que, al programar, se hace lo posible; y esa es la segunda historia. Pues la primera todos la conocemos.
El código encierra un relato secreto. Una historia. Que no es explícita, y pocas veces conocida por su autor. Se descubre con las siguientes preguntas: ¿Podré resolver el problema? ¿He podido entender lo qué me piden? ¿Tengo el conocimiento para resolverlo? Y, quizá, todavía más importante: ¿Tengo el conocimiento para resolverlo bien?
Por otro lado, la primera historia, tiende a tener un autoengaño dentro. Elegimos una tecnología, comenzamos a programar, con la esperanza de hacerlo lo más rápido posible, pues se debe terminar, y en informática, siempre se debe ser ágil. Perdemos. Siempre perdemos cuando vamos lento. Y si nos armamos de valor y decidimos ir lento, alguien de «arriba» ya nos hará entrar en razón, y volvemos a ir rápido. Una historia tan familiar.
Dudar. Criticar. Preguntar. Reflexionar. Son las palabras que tienen el antídoto a la segunda historia. El antídoto a nuestras limitaciones. Éste es un problema epistémico, diría un filósofo de la computación. ¿Cómo sé que sé? El «cielo digital» se despeja con más información; eso sí, con buena información. Los problemas de este tipo se resuelven con información que es tanto veraz como contrastable. Veraz significa quedarnos con lo que se sostiene por la evidencia; y, contrastable, que nosotros podemos verificar esa evidencia. En informática, la credulidad no es buena aliada. Y, me temo, que tampoco ayuda en ninguna área del conocimiento.
Para descubrir la segunda historia debemos pensar en ella como un problema epistémico, que es el problema del conocimiento. Un problema que siempre está ahí. Detrás de todo lo que programamos, independiente del lenguaje de programación. A veces nos damos cuenta de él; otras, simplemente no queremos mirarlo. ¿Por qué preocuparme por lo que no sé solucionar?
A mi lado, mientras escribo en la cafetería Sandwichez de la calle Bruc, una fuerte lluvia cae en Barcelona, algo poco común en el Mediterráneo, sobre todo, a la entrada de mayo. Pero como soy chilote: elijo no preocuparme. Me cruzo de brazo y ya. Recordando el dicho, «un chilote no le teme a la lluvia», pero yo ahora sí le temo. La falta de práctica agota el valor. Además, con la lluvia nada se puede hacer. Uno termina conociendo a su enemigo. Pero esto no tiene nada que ver con la segunda historia.
Con el conocimiento siempre hay algo que hacer.
En los últimos tiempos estoy aplicando un enfoque muy parecido: Lo que hacemos con nuestro código es una modelización de la realidad. De una parte reducida. Y a la que simplificamos enormemente. Los requerimientos definen la profundidad y la precisión de nuestro modelo. Porque muchas veces no es necesario ir más allá de cierta precisión en nuestro modelado.
Verlo así me ayuda a comprender hasta dónde llegar, y por qué. A limitar ese posible exceso de detalle en que podemos caer en el entusiasmo de proveer mejores soluciones por el simple placer de hacerlo mejor.
Quizá suene esto a una especie de glorificación de la mediocridad. Creo que no. Siempre podemos dar la mejor solución posible a una problema. pero es una cuestión de necesidad real lo que nos sirve como medida de las cosas, y no nuestro ego.
Nuestro mejor modelo de la realidad es el que sirve. El que puede ser empleado para obtener el resultado esperado. Emplear una cohete para misiones lunares para cruzar un río no es solamente espectacular. Es espectacularmente falto de proporción y de utilidad.