ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 10 no 2 Apr 1985 page 19
https://portalparts.acm.org/1020000/1012621/fm/frontmatter.pdf
La parábola de los dos programadores, continuación [1]
W.D. Maurer
Traducción de Enrique Latorres.
La última vez que dejamos a nuestros dos programadores, Alan y Charles, cada uno había producido el mismo programa, aunque de maneras muy diferentes. Alan acaba de ser ascendido a Analista de Sistemas como resultado de su liderazgo en un equipo de su compañía (AAAA) que produjo un programa de 2500 líneas. En su nuevo puesto, ya no es responsable de mantener ese programa. Mientras tanto, Charles, después de producir un programa equivalente de 500 líneas – de su empresa (CCCC), se ha desanimado y ha dejado CCCC por DDDD (División de Datos Distribuidos de Delaware).
Un año después, y sin que se conocieran una a la otra, como antes, nuestras dos compañías decidieron que sus respectivos programas debían ser modificados y ampliados, y, sorprendentemente, exactamente de la misma manera. Se espera que las modificaciones y expansiones, por parte de la gerencia, dupliquen aproximadamente el tamaño del programa.
En AAAA, el programa original tardó seis meses en ser escrito, utilizando la metodología de diseño estructurado PQR. Encontrar un nuevo programador que esté familiarizado con PQR lleva unas seis semanas. Cuando finalmente se contrata a Edwin, él, al igual que Alan, pide tres programadores más. Él se encargará del primer módulo principal; Frank, Gordon y Howard se encargarán de los módulos 2, 3 y 4, respectivamente.
Después de tres meses, el gerente de Edwin pide un informe de progreso. Afirma estar «a tiempo» en el módulo 1. Gordon también está a tiempo; Frank está claramente tambaleándose; y Howard ha terminado el módulo 4 y ha resultado ser inesperadamente fácil de arreglar. Howard ha consumido una cantidad considerable de tiempo de computadora para realizar pruebas exhaustivas de todas las posibilidades imaginables. Una vez hecho esto, dirigió su atención al módulo 2 y comenzó a trabajar en él, independientemente de Frank. Cuando Frank se enteró de esto, armó un escándalo político y consiguió que Howard fuera transferido del proyecto.
Seis semanas después Edwin y Gordon declararon que completaron sus módulos. Inmediatamente empezaron a buscar el módulo 2. En este punto Frank planteó otro lío político, pero esta vez perdió y fue transferido fuera del proyecto. Se contrataron dos programadores más, pero fueron asignados inmediatamente a un nuevo trabajo, ya que el gerente de Edwin estaba inundado de solicitudes.
Edwin y Gordon dividieron el módulo de Frank en dos partes y lo terminaron en tres meses más. El programa está ahora bajo prueba y, al igual que en el caso de Alan, los usuarios encuentran una serie de errores y deficiencias. Estos tardan cuatro meses en corregirse, en lugar de dos, porque ahora sólo hay dos programadores trabajando en ellos.
Después de un total de casi doce meses, la versión de producción del programa está completa. Tal y como estaba previsto, consta de casi 5.000 líneas de código. Es igual de quisquilloso sobre el formato de los datos de entrada, que la versión anterior aunque ahora, dado que se aceptan muchos más tipos de entrada, el personal de entrada de datos tiene que pasar por otro curso de formación.
Mientras tanto, en CCCC, se está desarrollando una historia muy diferente. Como antes, un programador recién contratado, John, que piensa que es realmente bueno, es contratado para hacer las modificaciones. John es tan aficionado a Space Invaders como lo fue Charles, pero es un poco más cuidadoso de no ser atrapado por su gerente mientras juega.
Al cabo de tres meses, John anuncia que ha completado las modificaciones. Presenta un programa que, maravillosamente, es de unas 1.000 líneas de código. El programa es probado y produce inmediatamente aullidos de decepción. Parece que, con los datos de entrada que fueron aceptados y procesados por el programa de Charles, el programa de John produce resultados completamente diferentes.
Hasta ahora John había estado usando sólo sus propios casos de prueba generados; nunca había usado datos «reales». Tuvo lugar una acalorada reunión. John insistió en que su programa hace lo que dicen las especificaciones. Al ver las especificaciones, tal como aparecen en la documentación de Charles (cerca de una página de documentación para todo el programa – – a Charles le encantaba ser conciso y resumido en todas las cosas), quedó claro que Juan simplemente había malinterpretado, desde el principio, lo que se suponía que el programa de Charles hacía.
John volvió al desarrollo por otros dos meses, esta vez con datos de pruebas reales. La segunda versión del programa de John funciona bien con los datos de prueba reales; los usuarios producen tres ejecuciones de datos de prueba reales más, y en cada una hay discrepancias entre la salida de John y la de Charles. Después de otro mes, la tercera versión está lista, y esta vez un nuevo usuario entra en la escena. Utiliza varias características del sistema que no se ejercitaron en las pruebas anteriores, y descubre un montón de nuevas discrepancias. John se ofrece a intentarlo de nuevo, pero su manager está disgustado y decide empezar de nuevo. Se contrata a un nuevo programador, Keith.
Keith pasa un mes trabajando con los usuarios y definiendo la naturaleza exacta del problema. Después de otro mes, Keith anuncia un gran avance. Su manager entra en la sala y descubre que Keith ha traducido el programa original de Charles a assembler (lenguaje ensamblador). Por cierto corre cinco veces más rápido que el original. El gerente ha leído en alguna parte que los programas de lenguaje ensamblador son muy difíciles de modificar. Traslada a Keith fuera del proyecto y trae a un nuevo programador, Larry.
A Larry le dan las voluminosas notas que los usuarios trabajaron para Keith. Se pasa un día leyéndolos y se pone a trabajar. Después de unas diez semanas el programa de Larry está listo. Pero es peor que el de John. Sin embargo, a diferencia de John, Larry nunca afirmó que su programa siguiera las especificaciones. Cuando se enfrentó a discrepancias obvias entre su programa y las especificaciones, Larry simplemente sonrió y dijo: «Vaya, así es; tienes razón». Pronto se hizo obvio que Larry no sabía leer inglés; sólo podía hacer cosas que inventa en su propia cabeza.
A Mike, el mejor programador de la empresa, se le pide que haga su intento. Desafortunadamente Larry ha perdido la única copia de las voluminosas notas, y Mike trata de re-derivarlas yendo por ahí y hablando con seis usuarios diferentes, cuatro de los cuales inmediatamente aúllan que Mike los está tratando con abierto desprecio (y realmente son intelectualmente inferiores a Mike). El gerente, muy acosado, mueve a Mike de vuelta a lo que estaba haciendo antes, y trae a Norman.
Norman es muy amable con los usuarios, y el gerente respira aliviado. Ya ha pasado un año, y Norman sigue trabajando, prometiendo «cualquier día de estos». Sin que este gerente de CCCC lo supiera, AAAA finalmente dejó ir a Frank, y Frank comenzó a usar su segundo nombre, que es Norman, y se fue a trabajar para CCCC.
AAAA tiene un programa de 5000 líneas que funciona. CCCC tiene el programa original de 500 líneas, que funciona, y tres programas ampliados de 1000 líneas, ninguno de los cuales funciona, además de la traducción de Keith al lenguaje ensamblador. La semana pasada, con el fin de mostrar al menos algún progreso, el programa de Keith se puso en producción. Los usuarios están impresionados con el aumento de la velocidad, pero hace tiempo que han perdido la esperanza de que alguna vez habrá un aumento de la funcionalidad.
W.D. Maurer
The George Washington University
Dept. of Electrical Engineering and Computer Science Washington DC 20052
The Parable of the Two Programmers — Still More
Tim E. Barrios
Espero que los lectores de la historia de Neil W. Rickert «La parábola de los dos programadores» no hayan interpretado su moral como contradictoria con los principios de la ingeniería de software. Más bien, creo que muestra lo que puede hacer una mala interpretación de los principios. La moraleja que me inspira la parábola es que «se obtiene lo que se paga» o, en términos de gestión de software, «se obtiene lo que se mide».
A juzgar por su obsesión con las «líneas de código», Automated mide la productividad y recompensa la cantidad de código. Además del problema de gestión, su metodología es muy débil ya que comenzaron a codificar antes que Charles (de Consolidated) quien, asumimos, usó poca o ninguna metodología formal. Charles pasó mucho más tiempo en las etapas de pre-codificación antes de producir «líneas de código» que habrían sido vistas por la gerencia de Automated como tiempo improductivo debido a su medida de productividad. Consolidated, por otro lado, instruyó a Charles para «abordar el trabajo» (resolver el problema). Sin interacción de la gerencia, resolvió el problema más productivamente que Automated, pero fue visto como menos productivo debido a la falta de tamaño y complejidad de la solución.
El malentendido sobre la complejidad es otro tema interesante. Ciertamente, el software no debe juzgarse por su complejidad (como hicieron ambos gerentes) o incluso simplemente por su falta de complejidad. La calidad se logra minimizando la complejidad de la solución en relación con la complejidad del problema en cualquier nivel adyacente de abstracción (requisito a diseño, diseño a código), etc. ) — el diferencial de complejidad. En el caso de este problema, cuya complejidad es la misma para ambas empresas, la solución que era menos compleja (Charles’) es ciertamente mejor y se refleja en el atributo de diferencial de complejidad de la «calidad». La dificultad de la parábola es la percepción por parte de la dirección sobre qué es la calidad (la solución más compleja fue elogiada y recompensada).
La definición de calidad de cada proyecto, definida por la ponderación de los atributos de calidad, guiará a los desarrolladores y mantenedores en la creación del producto. En el caso de Automated, la cantidad de «líneas de código» y la alta complejidad son aparentemente pesadas en su definición de calidad. Charles, sin dirección gerencial, percibía la calidad como un producto que cumplía la función deseada (resolvía el problema); incluso lo hacía más eficientemente que Automated porque nadie le dijo, hasta su revisión, que su gerente mide (paga por) un código complejo y voluminoso.
Al leer esta historia, recordé una regla que escuché mientras trabajaba en un proyecto de desarrollo muy grande: ningún proyecto de software se puede hacer efectivamente con más de 6 o menos de 200 personas. El único argumento que puede apoyar esta teoría es que tal vez la definición de efectividad (como calidad) se define de manera diferente dependiendo del tamaño del proyecto y de la actitud de la gerencia y, esperemos, del cliente y de los usuarios hacia la calidad deseada de la solución al problema.
Tim E. Barrios
Software Engineer
Harris GISD Software Operations R1/154 4
505 John Rodes Blvd.
Melbourne FL 32902
Phone 305-242-5396
Maurer, W. D., & Barrios, T. E. (1985). The parable of the two programmers, continued. ACM SIGSOFT Software Engineering Notes, 10(2), 19–22. doi:10.1145/1012621.1012623
[1] Se invita al lector a revisar la moraleja que puede haber derivado de «La parábola de los dos programadores» (SEN 10, 1[enero 1985]).
