Parábola de los dos programadores

La parábola de los dos programadores[1]
Neil W . Rickert
Dept. de Matemáticas, Estadística y Ciencias de la Computación,
Universidad de Illinois en Chicago.

Érase una vez, y sin que ninguna supiera de la otra, la «Automated Accounting Applications Association» y la «Consolidated Computerized Capital Corporation» decidieron que necesitaban el mismo programa para realizar un determinado servicio.
Automated contrató a un programador-analista, Alan, para resolver su problema. Mientras tanto, Consolidated decidió pedirle a un programador recién contratado, Charles, que se encargara del trabajo, para ver si era tan bueno como pretendía.
Alan, habiendo tenido experiencia en proyectos de programación difíciles, decidió utilizar la metodología de diseño estructurado PQR. Con esto en mente, le pidió al gerente de su departamento que asignara a otros tres programadores como equipo de programación.
Luego el equipo se puso a trabajar, elaborando informes preliminares y análisis de problemas.
De vuelta en Consolidated, Charles pasó algún tiempo pensando en el problema. Sus compañeros de trabajo notaron que Charles a menudo se sentaba con los pies en el escritorio, tomando café. Ocasionalmente se le veía en la terminal de su ordenador, pero su compañero de oficina podía darse cuenta por el golpeteo rítmico de las teclas de que en realidad estaba jugando a Space Invaders.
A estas alturas, el equipo de Automated estaba empezando a escribir código. Los programadores pasaban la mitad de su tiempo escribiendo y compilando código, y el resto de su tiempo en conferencia, discutiendo las interfaces entre los distintos módulos.
Su compañero de oficina notó que Charles finalmente se había dado por vencido con Space Invaders. En vez de eso, ahora dividía su tiempo entre beber café con los pies sobre la mesa y garabatear en pequeños trozos de papel. Su garabato no parecía ser Ta Te Ti, pero tampoco tenía mucho sentido.
Han pasado dos meses. El equipo de Automated finalmente publica un calendario de implementación. En otros dos meses tendrán una versión de prueba del programa. Luego, un período de dos meses de pruebas y mejoras debería dar como resultado una versión completa.
El gerente de Charles ya se ha cansado de verle hacer el tonto. Decide enfrentarse a él. Pero mientras entra en la oficina de Charles, se sorprende al ver a Charles ocupado introduciendo código en su terminal. Decide posponer la confrontación, así que charla un poco y se va. Sin embargo, comienza a vigilar más de cerca a Carlos, para que cuando la oportunidad se presenta puede enfrentarse a él. No esperando una conversación desagradable, se complace en notar que Charles parece estar ocupado la mayor parte del tiempo. Incluso se le ha visto retrasar su almuerzo y quedarse después del trabajo dos o tres días a la semana.
Al cabo de tres meses, Charles anuncia que ha completado el proyecto. Presenta un programa de 500 líneas. El programa parece estar claramente escrito, y cuando se prueba hace todo lo requerido en las especificaciones. De hecho, incluso tiene algunas características de comodidad adicionales que podrían mejorar significativamente la facilidad de uso del programa. El programa se pone a prueba y, a excepción de un descuido rápidamente corregido, funciona bien.
El equipo de Automated ya ha completado dos de los cuatro módulos principales requeridos para su programa. Estos módulos están siendo sometidos a pruebas mientras que los demás módulos se están terminando.
Después de otras tres semanas, Alan anuncia que la versión preliminar está lista una semana antes de lo previsto. Proporciona una lista de las deficiencias que espera corregir. El programa se pone a prueba. Los usuarios encuentran una serie de errores y deficiencias, además de los ya enumerados. Como explica Alan, esto no es ninguna sorpresa. Después de todo esto es una versión preliminar en la que se esperaban errores.
Después de unos dos meses más, el equipo ha completado su versión de producción del programa. Consta de unas 2.500 [2] líneas de código. Cuando se prueba, parece que satisface la mayoría de las especificaciones originales. Ha omitido una o dos características, y es muy quisquilloso con el formato de sus datos de entrada. Sin embargo, la empresa decide instalar el programa. Siempre pueden capacitar a su personal de entrada de datos para ingresar datos en el formato estricto requerido. El programa es entregado a algunos programadores de mantenimiento para eventualmente incorporar las características que faltan.
Secuela :
Al principio, el supervisor de Charles quedó impresionado. Pero al leer el código fuente, se dio cuenta de que el proyecto era mucho más simple de lo que había pensado originalmente. Ahora parecía evidente que esto no era un gran reto ni siquiera para un programador principiante.
Charles producía unas 5 líneas de código al día. Esto está quizás un poco por encima de la media. Sin embargo, considerando la simplicidad del programa, no fue nada excepcional. También su supervisor recordó sus dos meses de holgazanear.
En su siguiente revisión salarial, Charles recibió un aumento que fue aproximadamente la mitad de la inflación durante el período. No le dieron un ascenso. Después de un año se desanimó y salió de Consolidated.
Secuela:
Al principio, el supervisor de Charles quedó impresionado. Pero al leer el código fuente, se dio cuenta de que el proyecto era mucho más simple de lo que había pensado originalmente. Ahora parecía evidente que esto no era un gran reto ni siquiera para un programador principiante.
Charles producía unas 5 líneas de código al día. Esto está quizás un poco por encima de la media. Sin embargo, considerando la simplicidad del programa, no fue nada excepcional. También su supervisor recordó sus dos meses de holgazanear.
En su siguiente revisión salarial, Charles recibió un aumento que fue aproximadamente la mitad de la inflación durante el período. No le dieron un ascenso. Después de un año se desanimó y salió de Consolidated.
En Automated, Alan fue elogiado por completar su proyecto a tiempo. Su supervisor revisó el programa. Con unos minutos de pulsación, vio que los estándares de la compañía sobre programación estructurada estaban siendo observados. Sin embargo, rápidamente dejó de intentar leer el programa; parecía bastante incomprensible. Se dio cuenta de que el proyecto era mucho más complejo de lo que había asumido originalmente, y felicitó de nuevo a Alan por sus logros. El equipo había producido más de 3 líneas de código por programador y día. Se trataba de una cifra aproximada, pero, dada la complejidad del problema, podría considerarse excepcional. Alan recibió un fuerte aumento de sueldo y fue ascendido a Analista de Sistemas como recompensa por sus logros.

Traducido por Enrique Latorres, y alguna ayuda de https://www.deepl.com/en/translator .

The Parable of the Two Programmers
Neil W. Rickert
Dept. of Math, Stat., and Computer Science,
University of Illinois at Chicago.
ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 10 no 1 Jan 1985 page 16-18 ISSN:0163-5948 doi>10.1145/1012443.1012452
https://dl.acm.org/citation.cfm?doid=1012443.1012452
https://portalparts.acm.org/1020000/1012443/fm/frontmatter.pdf

[1] Se invita al lector a extraer su propia moral.

[2] Si esto parece irrazonable, pregunte a cualquiera que imparta regularmente cursos de informática en los que se requieran proyectos de programación. Una relación de cinco a uno entre el programa más corto y el más largo es bastante típica, y por lo general los programas más cortos son mejores.