Ingeniero de letras

  • 0

Ingeniero de letras

Con este post, el segundo de El valle de las letras, inauguro la sección Ingeniero de letras. Se trata además de un post bastante ambicioso, que lleva años dando vueltas en mi cabeza. Llegué incluso a pensar en la posibilidad de impartir una charla sobre esta temática, así que espero ser capaz de plasmar todo aquello que tengo en este momento en mente. Disculpas anticipadas, por si acaso no lo lograse.

En primer lugar, voy a empezar definiendo lo que para mí es un ingeniero de letras. No es ningún secreto que combino mi pasión por la literatura con mi oficio como profesor de informática y es ahí en donde nace el término Ingeniero de letras, término este que, si no está acuñado por mí, al menos le doto de mi propio significado. Para mí, ingeniera de letras es aquella persona que, siendo docta en asuntos más reservados para la ciencia y la ingeniería tales como las matemáticas, física, química o estadística entre otras, al mismo tiempo es, como mínimo “válido”, para aquellas materias comúnmente denominadas “de letras” como son la literatura, la historia, el arte, los idiomas…

En mi caso, trato de combinar todas las disciplinas, dejando aquellas que encajan en un perfil puramente humanístico para el ocio y reservándome las que corresponden con la rama científico-matemática para el ámbito laboral, que de algo hay que vivir. Y es por eso por lo que voy a hablar de las similitudes entre el trabajo de un escritor y el de un desarrollador informático.

Voy a empezar citando la manera en la que se enumeran las versiones del software en informática. Lo más habitual es emplear un sistema de numeración compuesto por dos o tres números separados entre sí por un punto. Algo así como 8.1 o 8.1.3. En este sistema el número más a la izquierda representa la versión del programa y una variación al alza de este valor supone un cambio total del programa que puede incluso conllevar una reestructuración completa de la interfaz o un cambio del manejo. El número central, sirve para indicar cambios menores dentro de una misma versión, como el añadido de una nueva funcionalidad o la solución de un error serio. Y, finalmente, el número de la derecha marca aquellos cambios insignificantes que el usuario no detectará a simple vista, como la corrección de algunos errores menores o pequeñas mejoras en el rendimiento.

En este aspecto, y puesto que no tengo constancia de que en el mundo de la literatura se utilice ningún sistema similar lejos de los conocidos “Primera edición”, “Segunda edición”, etc., yo directamente empleo el sistema informático para nombrar las diferentes versiones de las novelas conforme las voy escribiendo. Así diferencio un archivo del libro que estoy escribiendo de otro más antiguo porque este primero puede ser la versión 3.5.1 y el otro la versión 3.4.9.

Además, empleo los términos ALPHA, BETA, RC y RTM, tan empleados en el desarrollo del software informático. Para los que no estén puestos en la materia, un software se encuentra en estado Alpha cuando está en una fase preliminar de su desarrollo en la que permite disfrutar de algunas de las funcionalidades del programa, pero desde luego no de todas. Además, las que ya han sido implementadas (interesante palabra de la que hablaré después) no tienen porque ser totalmente funcionales. El software se encuentra en estado ALPHA hasta que finalmente se obtiene una versión totalmente funcional. Esta versión, que aún puede estar plagada de fallos que ir depurando ya puede ser llamada BETA. Cuando el software en estado beta alcanza la madurez suficiente para ser comercializado se saca una versión RC (Release Candidate o candidata para ser la versión definitiva) y si todo va bien, de ahí se saca una última versión llamada RTM (Release To Market o listo para vender).

Pues bien, después de toda esta explicación os reconoceré que yo utilizo estas mismas nomenclaturas para las diferentes versiones de mis obras. Así, por ejemplo, “El sillón del diablo”, mi opera prima, estuvo una vez en una versión Alpha, y permaneció así concretamente hasta 0.18.0 en la que obtuve una primera versión del libro que podía leerse desde el principio hasta el final, aunque esa versión aún guardaba muchas diferencias con la versión finalmente publicada. Después pasó por un periodo como BETA, en el que diversos cambios fueron haciéndose para mejorar la obra y hacerla “funcionar”. Esto me llevó hasta la versión 20.0.0, desde la cual pasé a la versión 20.1.0 que fue la RC que se convirtió en RCM en la versión 21.0.0, que fue la que finalmente vio la luz.

Otro aspecto curioso que tienen las versiones BETA es la existencia de unos usuarios llamados Betatester (Microsoft ahora los llama Insider). Un betatester no es más que una persona encargada de probar cada una de las betas para encontrar posibles errores en ellas y que puedan así ir corrigiéndose en sucesivas versiones en ese camino hasta la versión RCM. Usualmente hay dos tipos de betatester: privados y públicos. Cuando un programa está en fase de BETA privada, solo unos pocos elegidos pueden probar la aplicación. Cuando está en fase de BETA pública, el programa está disponible (generalmente de forma gratuita, aunque la versión final vaya a tener coste) para que quien quiera pueda probarlo. Antiguamente era común pagar por utilizar betatester pero Internet ha puesto a disposición de las empresas miles de personas interesadas en testar gratuitamente los programas, por lo que el paradigma ha tendido a cambiar.

Es curioso que este vocablo, betatester, si tiene su equivalente en el mundo literario: Lector cero. Un lector cero es aquella persona que se lee las versiones preliminares del libro para ayudar a detectar incongruencias o simplemente dar al autor su opinión. Vamos, un betatester de libros. Porque yo, como buen ingeniero de letras, siempre los he llamado, los llamo y los llamaré betatester. Como curiosidad, fue precisamente el empleo de lectores cero el que me llevó a crear un nuevo personaje en “El sillón del diablo”. Tras pasar el libro por varios probadores, descubrí cierta tendencia del lector a adivinar quien era el asesino (que en este caso no, no es el mayordomo) mucho antes de lo que yo tenía previsto, motivo por el cual cree a dicho personaje y volví a realizar los test, pertinentes, esta vez con resultados satisfactorios.

En realidad, haciendo eso, hice lo que en desarrollo de software se denomina implementar, en este caso, a un personaje. Si miramos hacia Wikipedia, una implementación “es la ejecución o puesta en marcha de una idea programada, ya sea, de una aplicación informática, un plan, modelo científico, diseño especifico, estándar, algoritmo o política”. Nótese que aquí no se menciona en ningún momento nada que tenga que ver con la literatura ni con el mundo de las letras, por lo que también me atribuyo la extensión del término al mundo del escritor. ¡Ay, que esclavo es ser ingeniero de letras!

Como curiosidad, explicaré lo que hago cuando un capítulo me queda desconectado (es decir, cuando llevo 12 capítulos y sucede que escribo uno que bien podría ser el 20, el 18 o quizás el 23 (eso es algo que no sabré hasta que llegue el modo de encajarlo en la obra). Es en ese momento cuanto en vez de mirar hacia las humanidades recurro a las matemáticas y cojo una de las 3 variables auxiliares más empleadas: X. ¿Que tengo dos capítulos desconectados? X e Y. Uso X, Y, Z si tengo tres y si ya son cuatro desdoblo variables: XX, XY, XZ, YX, YY…

Después de escribir, siempre viene la etapa de pulir detalles y revisar en busca de errores. En informática, a un error en el software se le denomina BUG (bicho) supuestamente, en alusión a una polilla que se introdujo en un relé de uno de los primeros ordenadores (el Mark II, en 1945) haciendo que este funcionase mal. Sin embargo, el término es anterior pues ya había sido utilizado antes por Thomas Edison en 1896 para describir el mal comportamiento de los dispositivos eléctricos.

Mi pequeño homenaje a Edison, al Mark II e incluso a la desdichada polilla (cuyo cadáver aún se conserva pegada a una hoja en el Museo Nacional de Historia Americana del Instituto Smithsonian en Washington, EEUU) es llamar BUG a cada uno de los errores que encuentro en mi libro. Así, si cuando quiero hablar de FELIPE II, en un momento determinado me equivoco y hablo de FELIPE IV, por ejemplo, estamos ante un BUG. Aunque claro, solo si eres un ingeniero de letras, si no, simplemente es un fallo.

La primera edición de “El sillón del diablo” contiene algunos (pocos) BUGS localizados y corregidos en la segunda edición. Uno de ellos es el nombre del paramédico que atiende a Gregorio Candelas, que cambia de nombre de Ricardo a Rodrigo repentinamente para volver a ser Ricardo nuevamente.

La labor de detectar y corregir BUGS en informática se denomina DEBUGUEAR o DEPURAR, palabras ambas que utilizo con frecuencia cuando me encuentro revisando mis borradores.

Finalmente, os hablaré de una de mis técnicas de ingeniera favoritas y de como me cambió la vida. Bueno, tal vez no tanto, pero al menos si el modo de escribir. Se llama Divide y vencerás y es uno de los paradigmas de diseño algorítmico más conocidos e importantes. Básicamente consiste en, cuando tenemos un problema muy complicado (computacionalmente hablando) se utiliza resolución recursiva para ir dividiéndolo en muchos subproblemas de menor calado. Recursivo significa que se va llamando así mismo un número determinado de veces que, en este caso, es el necesario para que ese gran problema de difícil solución se haya convertido en N problemas fácilmente solucionables. Según está máxima, es mejor diez problemas pequeños que uno grande.

Y alguno pensará en cómo esto ha podido cambiar mi forma de escribir, ¿verdad? Y aquí es donde os hago una pequeña confesión: durante años me he dedicado a escribir relatos cortos. Decenas de ellos, casi diría que cientos. Y cuando llegó el momento, cuando creí tener la madurez suficiente, intenté dar el paso a la novela. Pero ¿qué sucedió? Que no era capaz. Por más que lo intentaba no me salían historias largas, tan solo relatos largos, demasiado cortos para ser considerados novelas. La solución llegó cuando decidí adaptar la técnica Divide y vencerás a mi modo de escribir, fragmentando la historia que podía tener en mente y que inicialmente, por su complejidad, podría parecer inabordable, en muchas sub-historias más pequeñas (en el caso de “El sillón del diablo”, 44, contando con el Prólogo y el Epilogo). De este modo no escribo una novela, sino muchos pequeños relatos que se entrelazan entre sí y funcionan como un ecosistema generando entre todas, la ansiada novela. Ya no me planteo la historia grande, sino que me focalizo cada vez en esa pequeña porción de la historia a la que los escritores (y los lectores) llamamos capítulo pero que un programador bien podría llamar Función (una pequeña porción de código aislada del resto del programa). Sin embargo, no soy aún lo suficiente ingeniero de letras como para referirme así a mis capítulos.

De esta técnica y de como hacer novelas de larga duración hablaré en otro momento con más detenimiento. Por el momento, creo que ha llegado el momento de poner punto y final a este post. Pero no sin antes comentar un último que tienen en común los escritores y los desarrolladores software. En el fondo, programar no es tan diferente de escribir, pues ambos crean algo de la nada, mediante el empleo de un lenguaje y aunque uno recurra a la literatura y otro a los algoritmos matemáticos, a ambos, escritores y desarrolladores software, les une la creatividad.

¿Veis como el tema daba para una charla?


Deja una respuesta

Si te gusta este blog, no dejes de visitar mi web