"Se puede lograr (2003)"

Historia del desarrollo del sistema operativo Multics

• André Bensoussan, quien desarrolló el sistema operativo Multics, estuvo a cargo de las modificaciones principales del sistema de archivos.
• El administrador de VTOC era un subsistema que realizaba el movimiento de información de archivos entre disco y memoria, la gestión del pool de búferes de memoria compartida y la administración del espacio de información en el disco.
• André se encargó del diseño, la implementación y las pruebas del administrador de VTOC, avanzando en el diseño mientras dibujaba muchos diagramas.

Proceso de desarrollo y éxito

• Tom Van Vleck, coordinador del proyecto, tenía preocupaciones sobre el cronograma, pero se tranquilizó cuando André empezó a escribir el código.
• André escribía el código con lápiz en lugar de usar una terminal de computadora, y rechazó incluso la ayuda para tipear, realizando él mismo todo el trabajo.
• Finalmente, ingresó en la terminal el código limpio que había escrito con lápiz e intentó compilarlo; tras corregir algunos errores tipográficos, compiló con éxito.
• Al integrarlo en el sistema y probarlo, el administrador de VTOC funcionó perfectamente desde el principio.

La clave del éxito de André

• André escribió un programa perfecto usando únicamente un lápiz como herramienta.
• El único bug encontrado en el administrador de VTOC se debió a un error de Tom Van Vleck, quien había indicado incorrectamente el orden de llamada del procedimiento de manejo de errores.
• La forma de trabajo de André fue presentada como una historia sobre ingeniería de software en la edición de abril de 1994 de IEEE Computer, y fue actualizada en noviembre de 2003.

Opinión de GN⁺

• La historia del desarrollo del sistema operativo Multics por André Bensoussan muestra cómo un diseño minucioso y la concentración pueden producir un resultado perfecto.
• Cuando se compara el método tradicional de usar solo lápiz y papel con las complejas herramientas modernas de desarrollo de software, se enfatiza la importancia de un enfoque fiel a los fundamentos.
• Esta historia es un buen ejemplo que recuerda la importancia del trabajo previo cuidadoso y de las pruebas en el campo de la ingeniería de software, y también ofrece una lección importante para la formación en ingeniería.

[GN⁺]

Opiniones de Hacker News

• Resumen del primer comentario:

  • Requisitos claros: la razón por la que el software tiene menos errores y es rápido es porque cuenta con requisitos definidos con claridad. El software actual es ambiguo respecto a qué debe construirse y cambia continuamente por el enfoque "ágil". Si se les dan a los desarrolladores APIs claras y criterios bien definidos, la mayoría puede escribir código eficiente.

• Resumen del segundo comentario:

  • La capacidad de los programadores soviéticos: a partir de la experiencia de trabajar con un desertor soviético, se dice que los programadores soviéticos eran sobresalientes porque el acceso a las computadoras era muy limitado. Como tenían que programar con papel y lápiz, hacían un esfuerzo por lograr que funcionara bien desde el principio.

• Resumen del tercer comentario:

  • La importancia del espacio de trabajo personal: citando un comentario de la cuenta jrd259 en un hilo anterior de Hacker News, se enfatiza la importancia de tener un escritorio grande y un espacio de trabajo privado sin notificaciones.

• Resumen del cuarto comentario:

  • La experiencia de programar sobre papel: en la infancia, en casa del abuelo, se escribían programas de Turbo Pascal en una máquina de escribir sin computadora, y luego se ejecutaban en una PC. También se comparte la experiencia de pasar al papel una función de suma binaria del lenguaje de programación exótico Ziim que uno mismo creó, para encontrar y corregir errores. Se subraya que limitar el camino "fácil" puede llevar a escribir código mejor pensado.

• Resumen del quinto comentario:

  • La programación de antes: hacia el final de la era del "big iron", los programadores no eran muy distintos del personal de captura de datos. Los programas se escribían en papel, y el tiempo de cómputo era caro y valioso. Si aparecía un bug, no se podía corregir hasta reservar la siguiente ejecución de CPU. Esto fomentaba un enfoque cuidadoso. Hoy en día, el desarrollo de software avanza de forma iterativa depurando en el IDE.

• Resumen del sexto comentario:

  • Código escrito por André Bensoussan: se proporciona un enlace a código escrito por André Bensoussan.

• Resumen del séptimo comentario:

  • El tamaño del software en el pasado: en esa época, el software era mucho más pequeño que el actual, y la mayoría de los proyectos estaban en el rango de los megabytes, aunque seguían siendo demasiado grandes para "registrarlos" en un solo archivo.

• Resumen del octavo comentario:

  • Tareas de programación en la escuela: según la experiencia de un amigo, en la escuela las tareas de programación se entregaban en papel y una semana después se recibían los resultados. Ese "tiempo de compilación" de una semana fue una experiencia educativa que obligaba a revisar el trabajo dos veces.

• Resumen del noveno comentario:

  • Ausencia de ágil/scrum: como respuesta a cómo André pudo hacer ese tipo de trabajo, se señala que fue porque las metodologías de desarrollo ágil/scrum todavía no se habían concebido.

• Resumen del décimo comentario:

  • La experiencia de programar sobre papel: a los 14 años, en una clase de programación de secundaria, la mayor parte del código se escribía en papel. Como niño pobre de un país pobre, no había una PC en casa, y el clon de ZX Spectrum del laboratorio escolar no podía ejecutar el Turbo Pascal que se usaba.