Ayer vi vía Hacker News el enlace a un artículo que fue publicado el 20 de marzo de 1985 por Neil W. Rickert, miembro del Departamento de Informática de la Northern Illinois University. El texto ya había sido compartido antes -en Reddit hay una referencia a él de 2006, por ejemplo- pero yo desde luego no lo conocía y no he podido evitar compartirlo por si alguno tampoco lo había leído antes.

Como es un texto en inglés algo largo, me he animado a intentar traducirlo, así que disculpas por los posibles errores. El texto original está aquí, por si preferís leerlo directamente tal y como fue redactado.

      Érase una vez que, sin saber nada la una de la otra, la “Automated Accounting Applications Association” y la “Consolidated Computerized Capital Corporation” decidieron que necesitaban el mismo programa informático para proporcionar cierto servicio. 

     Automated contrató a un analista programador, Alan, para solucionar su problema.

     Mientras tanto, Consolidated decidió pedir a un programador de bajo nivel recién contratado, Charles, que abordase la tarea para ver si era tan bueno como él decía ser.

     Alan, que tenía experiencia en proyectos complejos de programación, decidió utilizar la metodología de diseño estructurado PQR. Con esa idea en mente, le pidió a su jefe de departamento que le asignara otros tres programadores para formar un equipo de programación. A continuación el equipo se puso a trabajar y a producir tanto informes preliminares como análisis del problema. 

     En Consolidated Charles dedicó algún tiempo a pensar en el problema. Sus compañeros de trabajo se dieron cuenta de que a menudo Charles se sentaba con sus pies sobre la mesa mientras se tomaba un café. Ocasionalmente se le vio frente a su terminal, pero su compañero de oficina podía deducir por la pulsación rítmica de las teclas que en realidad estaba jugando a Space Invaders. 

     Por entonces el equipo de Automated estaba comenzando a picar código. Los programadores pasaban la mitad de su tiempo escribiendo y compilando código, y el resto de su tiempo en reuniones, debatiendo sobre las interfaces que debía haber entre los distintos módulos. 

     El compañero de Charles notó que por fin había abandonado Space Invaders. En lugar de eso ahora invertía su tiempo en beber café con sus pies encima de la mesa y en hacer garabatos en pedacitos de papel. Sus garabatos no parecían tener relación con las Tres-en-raya, pero tampoco es que tuvieran mucho más sentido. 

      Pasaron dos meses. El equipo de Automated por fin publicó una hoja de ruta. En otros dos meses tendrían una versión de pruebas del programa. Tras eso vendría un periodo de dos meses de evaluación y mejora que debería llevar a una versión completa. 

     El jefe de Charles ya estaba cansado de verle holgazanear. Decide enfrentarse a él. Sin embargo, nada más entrar en la oficina de Charles se sorprende al verle muy ocupado introduciendo código en su terminal. El jefe decide posponer la confrontación, así que charla brevemente con él y se marcha.  Sin embargo, comienza a vigilar más de cerca a Charles para que en cuanto se presente la ocasión pueda enfrentarse a él. Como no tiene muchas ganas de tener una conversación desagradable, está encantado de que Charles parezca estar ocupado la mayor parte del tiempo. Incluso se le ha visto retrasar la hora del almuerzo y también quedarse a trabajar más allá de su hora de salida dos o tres días a la semana. 

     Al cabo de tres meses, Charles anuncia que ha completado el proyecto. Entrega un programa de 500 líneas. El programa parece estar escrito de forma clara, y al ser evaluado hace todo lo que se requería en las especificaciones. De hecho, incluso tiene algunas características adicionales muy convenientes que podrían mejorar de forma significativa la usabilidad del mismo. El programa se pone a prueba y, salvo por un despiste que corrigen rápidamente, funciona bien. 

      El equipo de Automated ya ha completado dos de los cuatro módulos principales del programa a estas alturas. Esos módulos están siendo sometidos a pruebas mientras que el resto de módulos se finalizan. 

      Tras tres semanas, Alan anuncia que la versión preliminar está disponible una semana antes de lo que marcaba la planificación. Proporciona una lista de defectos que espera corregir. El programa se pone a prueba. Los usuarios detectan varios errores y defectos aparte de los registrados por Alan. Como Alan explica, eso no es ninguna sorpresa. Después de todo, esta es una versión preliminar en la que los errores son esperables. 

      Después de dos meses más, el equipo termina de programar la versión de producción del programa. Consiste en cerca de 2.500 líneas de código. Al evaluarlo parece satisfacer la mayoría de las especificaciones originales. Se han omitido una o dos características, y el programa es muy exigente en el formato de sus datos de entrada. Sin embargo la empresa decide implantar el programa. Siempre podrán formar al personal de entrada de datos para introducir esos datos en el formato estrictamente necesario. El programa se pasa a varios programadores de mantenimiento para que incorporen en algún momento las características que faltan. 

      Epílogo:

      Al principio el supervisor de Charles se muestra impresionado. Sin embargo, a medida que analiza el código fuente se da cuenta de que el proyecto era en realidad mucho más simple de lo que había imaginado inicialmente. Ahora parece evidente que esto no era ningún reto, ni siquiera para un programador novato.

      Charles ha producido cerca de 5 líneas de código al día. Quizás ligeramente por encima de la media. Sin embargo, considerando la simplicidad del programa, no se trata de nada excepcional. Además, su supervisó tomó en cuenta que había pasado dos meses holgazaneando. 

     En su siguiente revisión de sueldo a Charles le dan un aumento que era cerca de la mitad de la inflación durante ese periodo. No se le dio ningún ascenso. Cerca de un año después Charles dejó de estar motivado y abandonó Consolidated.

      En Automated, Alan fue felicitado por terminar el proyecto a tiempo. Su supervisor le echó un vistazo al código. A los pocos minutos de hojearlo observó que los estándares de la empresa relacionados con la programación estructurada se habían respetado. Sin embargo, dejó de revisar el programa rápidamente; parecía bastante incomprensible. Se dio cuenta de que el proyecto era mucho más complejo de lo que a él le había parecido inicialmente, y felicitó de nuevo a Alan por su logro. 

      El equipo produjo unas tres líneas de código al día por cada programador. Una cifra más o menos en la media pero que considerando la complejidad del problema podría ser considerada como excepcional. A Alan se le dio un considerable aumento de sueldo, se le ascendió a Analista de Sistemas y se le dio una recompensa por su labor.