El programador ciego

Hace mucho tiempo, en un mundo alejado de la vida real, vivían seis programadores que pasaban las horas compitiendo entre ellos para ver quién era de todos el mejor desarrollador de software.

Para demostrar su conocimiento, los programadores explicaban las historias más fantásticas sobre algoritmos que se les ocurrían y luego decidían de entre ellos quién era el mejor programador.

Así pues, cada tarde se reunían alrededor de una mesa y mientras la última tarea de Jenkins compilaba y leían muy despacio los debates más votados esa semana en StackOverflow, el primero de los programadores adoptaba una actitud severa y empezaba a relatar la historia que según él, había vivido aquel día. Mientras, los demás le escuchaban entre incrédulos y fascinados, intentando imaginar las escenas que éste les describía con gran detalle.

La historia trataba del modo en que, viéndose libre de ocupaciones aquella mañana, el programador había decidido descargarse el código fuente de V8, y crosscompilarlo para todos los dispositivos de los cuales disponía. El programador contó que, de pronto, en medio de una gran sorpresa, se le había aparecido el Linus Torvals, el cual sacó de su mochila un pc con linux, y compiló con gran maestría el kernel de Linux a su lado. Linus al recibir los elogios del programador, decidió concederle el poder del Clean Code, que según él, le convertía en uno de los programadores con más talento que existía.

Cuando el primero de los programadores acabó su historia, se puso en pie el segundo de los programadores, y mientras movía sus manos sobre un Leap Motion, anunció que hablaría del día en que había presenciado él mismo la famosa presentación del lenguaje Swift, el innovador e interactivo lenguaje de Apple. Según él, esto ocurrió cuando el mismo Tim Cook le llamó por teléfono desde las oficinas de Cupertino para invitarle al evento de Apple más esperado del año, todo esto lo dijo entre risas mientras acariciaba su taza de café con el logo impreso de JAVA.

Para poder estar a la altura de las anteriores historias, el tercer programador encendió su ordenador y mostró su interfaz repleta de terminales y servidores de Node.js ejecutándose en tiempo real. Después de haber probado Node.js en producción, el programador estuvo horas y horas hablando sobre el magnífico tiempo de respuesta que tenía Node.js frente a otras plataformas como httpd de Apache.

Al acabar, fue el turno del cuarto programador, después del quinto y finalmente el sexto programador se sumergió en su relato. De este modo los seis programadores pasaban las horas más entretenidas y a la vez demostraban su ingenio e inteligencia a los demás.

Sin embargo, llegó el día en que el ambiente de calma se turbó y se volvió en enfrentamiento entre los programadores, que no alcanzaban un acuerdo sobre la forma exacta de hacer una release a producción. Las posturas eran opuestas y como ninguno de ellos había hecho una release a producción nunca, decidieron crear un documento en el que cada uno opinaría sobre como debería ser el proceso de release a producción, y de este modo poder salir de dudas.

Tan pronto como el administrador de Google Apps creó el documento, los programadores empezaron a bosquejar sus ideas sobre él. No había pasado mucho tiempo cuando de pronto, observaron un cambio en la línea de tiempo de twitter de una lista que todos seguían, apareció un tweet sobre como Amazon realizaba las releases a producción. Rápidamente hicieron todos click en el artículo, como disponían de la versión Canary de Google Chrome compilada por ellos mismos, el artículo cargó en milésimas de segundo.

Los seis programadores estaban llenos de alegría, y se felicitaban los unos a otros por su suerte. Finalmente podrían resolver el dilema y decidir cuál era la verdadera forma de realizar una release a producción.

El primero de todos, el más decidido, se puso sus gafas de lectura para empezar sin más dilación una lectura pausada y tranquila del artículo. Sin embargo, las prisas hicieron que se metiera sin querer una pata de las gafas en el ojo, impidiéndole leer la totalidad del artículo.

-¡Oh, compañeros míos! -exclamó- yo os digo que una release a producción se puede hacer perfectamente con el API Java de Amazon S3.

Llegó el turno del segundo de los programadores, que leyó con más precaución, imprimió en unas hojas el artículo y procedió a leerlo con una luz tenue sobre su cabeza, a la vez que estaba tumbado en su puff favorito, con tan mala suerte, que se quedó dormido leyendo la segunda hoja.

-¡Oh, hermanos míos! -exclamó cuando despertó- ¡Yo os digo que la mejor forma de realizar una release, es crear una tarea en Jenkins que suba los binarios a S3!

El resto de los programadores no podían evitar burlarse en voz baja, ya que ninguno terminaba de creerse lo que los otros programadores decían. El tercer programador empezó a leer el artículo en su Kindle. Después de una larga tarde leyendo, el dispositivo se quedó sin batería suficiente para que el programador pudiera leer las últimas 30 páginas que le faltaban,

-Escuchad queridos compañeros, el proceso de release a Amazon se puede hacer con S3cmd.

Los demás programadores disentían en silencio, ya que en nada se parecía al proceso de release que cada uno tenía en mente. Era el turno del cuarto programador, que decidió llamar por teléfono a su amigo que trabajaba en Google. El programador preguntó a su amigo que proceso de release a producción seguían en Google, escuchó atentamente todos los pasos y los anotó en su libreta para que quedara constancia del esfuerzo que había invertido en aprender el proceso de release de Google.

-¡Ya lo tengo! - dijo el programador lleno de alegría- Yo os diré cual es la verdadera forma de realizar una release a producción, simplemente hay que deslocalizar los servidores y sincronizar las tareas de Jenkins para que desplieguen los últimos commits de los repos.

El quinto de los programadores tomó el relevo y decidió no leer el artículo puesto que le parecía irrelevante. Recordó que hace 15 años un ingeniero de IBM publicó un libro sobre buenas prácticas de entregables en proyectos de JAVA.

-Ninguno de vosotros ha acertado en la forma de hacer una release. El método tradicional de realizar una release a producción en empresas serias, consiste en paralizar los servicios con un mensaje de 'mantenimiento' y desplegar los cambios sobre todas las máquinas que sean necesarias.

El sexto programador era el más viejo de todos, fundador de diferentes consultoras del país, conocía los entresijos de las releases a producción, o eso pensaba él. Revisó su correo electrónico personal y encontró aquellos documentos sobre especificaciones funcionales que describían cada paso necesario para realizar una release a producción, incluso especificaba el color de los botones y el diseño de las ventanas de error.

-¡Compañeros! Sin duda ahora lo tengo claro, el proceso correcto para realizar una release a producción consiste en reunir a los jefes de proyecto y delegar las tareas en los programadores de cada equipo.

Ahora todos habían experimentado por ellos mismos cuál era la forma correcta de realizar una release, y creían que los demás estaban equivocados. Satisfecha así su curiosidad, volvieron a darse las manos, escribieron sus punto de vista en el documento y se sentaron de nuevo en sus puestos informáticos orgullosos del tiempo que habían invertido en escribir aquél documento.

Otra vez sentados bajo la misma luz de la oficina, retomaron la discusión sobre la verdadera forma de realizar una release a producción, seguros de que lo que habían experimentado por ellos mismos era la forma correcta de hacerlo.

Seguramente todos los programadores tenían parte de razón, ya que de algún modo todas las cosas que habían experimentado eran ciertas, pero sin duda todos a su vez estaban equivocados respecto a la forma real de realizar una release a producción.