- Durante la reorganización del sistema de archivos de Multics en Honeywell Cambridge, André Bensoussan estuvo a cargo del VTOC manager, un subsistema central, y lo llevó desde el diseño hasta las pruebas
- Este módulo tenía que mover la información descriptiva de archivos entre disco y memoria, además de gestionar el buffer pool y hasta el espacio en disco, por lo que en la práctica se parecía más a un pequeño administrador de memoria virtual
- André no programaba directamente frente a la terminal, sino que pulía diagramas y código con lápiz mientras intentaba crear un diseño simétrico que también contuviera la información de estado
- Después de ingresar el manuscrito final, en la primera compilación solo aparecieron 3 errores tipográficos, y la ejecución enlazada al sistema también tuvo éxito en el primer intento
- El único bug encontrado después surgió porque Tom Van Vleck informó mal el orden de llamada del procedimiento de manejo de errores, así que el nivel de acabado del programa en sí era extraordinariamente alto
Trabajo en el VTOC manager de Multics
- André Bensoussan trabajó junto con Tom Van Vleck en el sistema operativo Multics en Honeywell Cambridge
- Un cambio grande en el sistema de archivos requería un subsistema llamado VTOC manager
- Mover la información descriptiva de archivos entre disco y memoria
- Administrar el buffer pool de memoria compartida
- Gestionar el espacio en disco para la información de archivos
- Por estas funciones, el VTOC manager tenía que operar como un pequeño administrador de memoria virtual
- André se encargó del diseño, la implementación y las pruebas de este módulo
Un programa terminado con lápiz
- André primero se sentaba en su escritorio y dibujaba muchos diagramas
- Quería una forma agradable de ver y simétrica que al mismo tiempo contuviera toda la información de estado
- A su alrededor incluso se preocupaban porque, por el calendario, la escritura del código se estaba retrasando
- También programaba con lápiz, no en la terminal
- Rechazó ayuda para tipear
- Reescribió partes, las copió, las borró y las corrigió hasta producir el manuscrito final
- Después de ingresar todo el manuscrito final hecho a lápiz en la terminal, la primera compilación falló, pero logró compilar tras corregir 3 errores tipográficos
- Al enlazarlo con el sistema y ejecutarlo, funcionó en el primer intento, y después el VTOC manager siguió funcionando perfectamente
- El único bug detectado se originó porque Tom Van Vleck, cuando André le preguntó, respondió sin verificar y adivinó el orden de llamada del procedimiento de manejo de errores
- Cuando ese camino de error se recorrió por primera vez, ocurrió un crash
- Fuera de eso, no había problemas en el programa
1 comentarios
Opiniones de Hacker News
Creo que la razón principal por la que él pudo hacerlo fue que los requisitos estaban definidos con mucha claridad.
Una gran razón por la que hoy el software tiene tantos bugs y es lento es que nadie sabe realmente qué se está construyendo o, si lo sabe, cambia constantemente por culpa de “Agile”.
Si le das a un desarrollador una API clara y criterios bien definidos, la mayoría escribe código que funciona muy bien.
Los requisitos no son poner listas y tickets en un tablero Kanban, sino aprender de verdad el dominio de lo que se va a construir.
Puedes construir algo en un área que no entiendes, pero el resultado suele terminar siendo basura; y está bien si aceptas ese proceso de escribir basura como un borrador para aprender el problema del dominio y las posibles soluciones.
No hay atajos para la calidad.
Si eres stakeholder, las personas que construyen la aplicación deberían poder acercarse a ti, y debes asegurarte de que entiendan el dominio. Se puede hacer sin estar encima de ellos todo el tiempo.
Hay que tener cuidado con los charlatanes que sueltan palabras de moda.
Si eres diseñador o programador, debes asegurarte de que los stakeholders y los expertos del dominio estén activos e involucrados. De lo contrario, extraer requisitos y entendimiento se vuelve tan difícil como sacar dientes.
Algunos stakeholders quizá ni siquiera quieran resolver el problema, puede que hayan querido ir en una dirección totalmente distinta o estén resentidos por razones políticas. Pocas cosas hunden un proyecto tanto como un stakeholder flojo o indiferente.
Los stakeholders no saben lo que quieren, pero aun así piden funcionalidades adicionales al azar o cambios enormes.
Terminas necesitando montones de excepciones porque se intenta forzar la herramienta a hacer cosas para las que no debería usarse.
Los diseñadores muchas veces crean diseños que chocan con las funciones necesarias, el comportamiento de los sistemas existentes y las necesidades de los stakeholders, y los equipos que desarrollan cada parte del sistema construyen en silos sin comunicarse bien.
Un proceso “Agile” mal diseñado intenta meter todo en un plazo determinado según estimaciones dudosas.
Al final, estos problemas hacen que el sistema no funcione como se esperaba o lo convierten en una bola de bugs.
Si creas un entorno donde los requisitos son claros y no cambian, los miembros del proyecto se comunican bien y puedes controlar por completo el proceso, las cosas salen bien. El caso del texto original también parece ser así.
Trabajo principalmente en empresas grandes, y el 90–99% del trabajo que entra corresponde al caso promedio.
Pero hay innumerables casos especiales tipo unicornio que ocurren una vez cada tres años, justo cuando hay un eclipse lunar y solar al mismo tiempo y las brujas cantan hechizos en el bosque.
Como esos casos deben implementarse en código en vez de manejarse manualmente, aparecen bugs y aumenta mucho el código que hay que revisar y mantener.
Ni empecemos con el mantenimiento. Es un punto doloroso.
Los requisitos siempre cambian. Es como una fuerza de la naturaleza; no existe un mundo donde todos sepan desde el principio qué van a construir, reciban una API completamente especificada y se metan en una cueva solo a implementarla.
La realidad nunca funciona así, y si necesitas esas condiciones, la ingeniería de software no es la profesión adecuada para ti.
Si no hubiera usuarios, mi software sería perfecto ;)
Una vez trabajé con alguien que había desertado de la Unión Soviética. Decía que los programadores soviéticos eran excelentes porque el acceso a computadoras era muy limitado.
Si tienes que programar con lápiz y papel, te dan ganas de que funcione en la primera ejecución.
Por casualidad, trabajábamos en Honeywell.
Entonces, ¿era un buen método de enseñanza o un buen filtro para excluir a la gente menos motivada?
En la escuela no podíamos usar computadoras durante la clase, así que estaba acostumbrado a programar e incluso depurar en papel.
Al llegar a casa lo tecleé y lo ejecuté, y me dio curiosidad si podría recrear la anécdota de Multics que había leído antes.
La primera compilación falló, pero después de corregir el nombre de una variable funcionó perfectamente.
Durante algunos años recuerdo que, en el ciclo editar→compilar→salida, el listado impreso era mucho mejor que una terminal. Era difícil ver, moverse por el código y modificarlo de forma eficiente.
Con mejores editores visuales, terminales más grandes y compilación y ejecución más rápidas, finalmente mejoró.
Como analogía, era parecido a las primeras armas de fuego: la transición desde el arco largo fue ineficiente por la pólvora húmeda, los mecanismos de chispa poco fiables y la necesidad de empujar todo dentro del cañón.
En el hilo anterior de HN sobre este artículo hay un buen comentario de la cuenta jrd259, que trabajó con André: https://news.ycombinator.com/item?id=18415231
Trata sobre lo importante que es tener un escritorio amplio y un espacio de trabajo personal sin notificaciones.
Me vienen a la mente dos veces en mi vida en las que programé en papel
La primera fue cuando tenía unos 10 a 12 años. Fui a la casa de mis abuelos, donde no había computadora ni smartphone, pero sí una máquina de escribir mecánica que podía alternar con una palanca entre tinta negra y roja
En esa época mi hobby principal era Turbo Pascal, así que escribí a máquina un programa en Pascal para luego, al volver a casa, ingresarlo en la PC y ejecutarlo
Como estuve una semana en la casa de mis abuelos, tuve tiempo suficiente para pensarlo bien, depurarlo a mano y volver a tipear las partes equivocadas
La segunda vez tiene que ver con el lenguaje de programación esotérico que hice, Ziim(https://esolangs.org/wiki/Ziim), y la función de suma binaria de esa página
Esa función era enorme y compleja, y tenía un bug. Sabía que tenía un bug porque la había ejecutado en el intérprete, pero no sabía dónde estaba el problema ni cómo arreglarlo
Justo tuve que tomar un autobús de larga distancia de unas 6 horas, y era la oportunidad perfecta para depurar
Copié la función de suma de Ziim con lápiz en papel cuadriculado y la ejecuté a mano, paso por paso, durante el viaje. Pude encontrar y arreglar el bug, y tuve que rehacer por completo la disposición de la función
Creo que la lección es que limitar deliberadamente la capacidad de hacerlo de la manera fácil a veces puede llevar a código mejor pensado
Aun así, normalmente no trabajo así. También voy directo a usar snippets a medias e iterar, o a ejecutar línea por línea con el depurador. Quizás debería replanteármelo
Pero si haces todo en papel, al final no es tan distinto de hacerlo directamente en la computadora. Terminas anotándolo todo y pierdes esa abstracción y esa prudencia
Cuando empecé, era el final de la era de las “computadoras grandes”
En aquellos tiempos, un “programador” solía ser más bien un empleado de entrada de datos, y a menudo era una mujer
Quienes escribían software redactaban programas en papel, en oficinas llenas de humo de cigarrillo
El tiempo de cómputo era caro y escaso. Si aparecía un bug durante la ejecución, no tenías oportunidad de arreglarlo hasta volver a reservar tiempo de entrada de datos y también tiempo de CPU
Por eso se fomentaba el enfoque de medir dos veces y cortar una
La mayor parte del software de entonces era bastante modesto comparado con lo que hoy damos por sentado, así que hacerlo así era más fácil. Además, la entrada y salida del software era extremadamente limitada, ni siquiera existía el término UI, y conectar periféricos era todo un asunto
Hoy en día, al escribir software a menudo se hace eso de “tirarlo contra la pared a ver qué se pega”. Es más fácil escribir código a medias y depurarlo en el IDE
Mi desarrollo de software tiende a ser iterativo, y escribí sobre eso aquí: https://littlegreenviper.com/miscellany/evolutionary-design-...
Recuerdo una tarea de la universidad en la que tenía que escribir un kernel de sistema operativo sencillo
No conocía bien C y no sabía más que la teoría de lo que hace un kernel, pero tenía que escribir unos cientos de líneas de código C para la gestión de tareas
Pensé que, si este programa no funcionaba, al ser código paralelo casi no tendría forma de depurarlo, y los bugs aparecerían como condiciones de carrera imposibles de identificar
Razoné todo el sistema y, durante varios días, escribí muchas funciones pequeñas e independientes pensándolas con muchísimo cuidado
Luego compilé y ejecuté, y después de corregir el clásico error de compilación de “falta un punto y coma”, funcionó en la primera ejecución
Cada vez que se publica un logro impresionante, los comentarios suelen ponerse a buscarle defectos. Ojalá dejaran de hacerlo
No son personas diseñando un gestor de memoria virtual para un nuevo sistema operativo, sino simples engranajes dentro de una máquina que convierte consultas SQL en HTML para mostrarles anuncios a niños y ancianos
Es inevitable volverse cínico y amargado
En realidad no deberíamos. Eso es precisamente lo que debe ser una discusión
En parte tienes razón, pero una mejor pregunta para orientar la conversación en positivo sería esta: ¿cómo podemos llegar, en el entorno corporativo actual, a un estado en el que sea posible un logro similar?
Cada vez que veo una reacción así, suele ser eso. El tamiz de moderación por usuarios simplemente tarda un poco en hacer subir los mejores comentarios
Si esta persona hubiera enfrentado el desafío que yo viví, se habría derrumbado ahí mismo
En esa época, el software era mucho más pequeño.
Hoy en día, apenas un proyecto crece un poco más que un programa de juguete, la mayoría ya está en megabytes, y es imposible “ir escribiéndolo” como un solo archivo.
Esto es más grande y complejo que aquello en lo que trabaja la mayoría hoy. Mucho del trabajo actual se parece más a código pegamento sobredimensionado para unir cosas como CRUD/REST.
Puede ser menor que la cantidad total de líneas de código de un proyecto completo, pero es más grande que las unidades con las que la gente suele lidiar. Además, esto también es solo una parte del código completo del sistema operativo.
Es todo el “administrador que gestiona la información descriptiva de archivos”. Tenía que transportar información de archivos entre el disco y la memoria, administrar un pool compartido de búferes en memoria y también gestionar el espacio en disco para esa información.
¿Qué pasaría si hoy le pidiéramos a la mayoría de los programadores que escribieran, en el lenguaje que eligieran, algo con los mismos requisitos y semántica?
La mayoría se perdería desde la etapa de imaginarlo. Mucho más difícil aún sería escribirlo en papel, teclearlo y hacerlo funcionar.
Una pequeña parte son URLs de componentes electrónicos, pero casi el 90% es simplemente texto en inglés. Otro 10% son citas de textos de otras personas, páginas web, notas de aplicación de fabricantes, libros, etc.
Es un solo archivo, y probablemente seguirá siendo un solo archivo durante el resto de este año y más. Si continúa al mismo ritmo, llegará a 12 megabytes. No es algo imposible en absoluto.
Si les interesa, pueden hacer git clone http://canonical.org/~kragen/sw/leatherdrink.git
Por ahora dejé commiteado el toolchain de avr, así que son casi 200 megabytes, y también hay fotos, videos, esquemáticos y cosas así.
Si fuera un lenguaje de programación, el crecimiento mensual en bytes sería menor, pero probablemente por un factor de cinco.
El código escrito por André Bensoussan está aquí: https://multicians.org/vtoc_man.html
Me senté en el escritorio para empezar a trabajar y terminar una tarea que venía evitando; naturalmente, se me fue la mente y me dieron ganas de revisar noticias en reddit o HN.
Abrí HN y el primer título era este:
“Se puede hacer”
Me motivó.
PD: claro, también leí el artículo :)
“¿Cómo hizo André esto sin ninguna herramienta más que un lápiz?”
Cuando entré a la preparatoria a los 14 años, en la clase de programación escribíamos la mayor parte del código en papel.
Era un chico pobre de un país pobre; no solo no tenía PC en casa, sino que las pocas “computadoras” del laboratorio de la escuela eran clones de ZX Spectrum que no podían ejecutar Turbo Pascal, el lenguaje de programación que usábamos en ese momento.