Se Puede Hacer (2003)
Las anécdotas sobre André Bensoussan diseñando por completo en papel un componente complejo del sistema de archivos de Multics provocan un debate más amplio sobre cómo se hacía —y aún podría hacerse— el software con enfoque profundo, requisitos claros y herramientas mínimas. Los comentaristas contraponen la época de oficinas silenciosas, sistemas pequeños pero conceptualmente difíciles y una sólida maestría del dominio con los flujos de trabajo actuales impulsados por interrupciones, especificaciones cambiantes bajo “ágil” y pilas extensas de dependencias mal documentadas. Muchos ven el diseño cuidadoso previo, la colaboración estrecha con expertos del dominio y los documentos de diseño escritos como habilidades infravaloradas que podrían mejorar significativamente la calidad del software moderno, aunque las restricciones que antes obligaban a ese rigor ya no existan.
Programación con lápiz y papel y contexto histórico
- Muchos recuerdan haber aprendido o trabajado con acceso a computadoras muy limitado (papel, tarjetas perforadas, ciclos de compilación de una semana).
- Esto obligaba a razonar con cuidado, a hacer menos iteraciones y, a menudo, llevaba a código que funcionaba en la primera ejecución.
- Varios ven la historia de Multics como parte de una era más amplia de “mide dos veces, corta una” en la que el tiempo de cómputo era escaso y los terminales no distraían.
- Otros señalan que esto también pudo haber funcionado como filtro: solo las personas muy motivadas persistían bajo esas condiciones.
Requisitos, casos límite y especificaciones cambiantes
- Hay un fuerte acuerdo en que unos requisitos claros y estables, y unas APIs bien definidas, hacen mucho más alcanzable el código de alta calidad.
- Problemas modernos: objetivos ambiguos, comentarios tardíos de las partes interesadas, cambios constantes de alcance etiquetados como “ágil”, y presión por plazos y “velocidad”.
- Debate sobre ágil: algunos dicen que responde a cambios inevitables en los requisitos; otros dicen que normaliza el cambio constante y fomenta cambios irresponsables.
- Los casos límite son una gran fuente de errores y complejidad. Algunos argumentan que los casos raros deberían manejarse manualmente; otros dicen que, a escala, incluso un 1% afecta a millones y debe diseñarse ingenierilmente.
Diseño, documentación y pensar antes de programar
- Varios subrayan que poder escribir el problema y la solución propuesta es una señal de verdadera comprensión.
- Los documentos de diseño breves y los diagramas se presentan como herramientas de pensamiento, no como burocracia.
- Algunos tienen dificultades para diseñar en papel y afirman que solo entienden los sistemas mientras escriben e iteran; otros dicen que es una habilidad que se puede entrenar.
- Se sugiere el desarrollo guiado por pruebas como un análogo moderno de “diseñar primero”.
Conocimiento del dominio y mentalidad de ingeniería
- Una razón clave por la que el logro de Multics fue posible: el programador también era un experto profundo en el dominio.
- Muchos sostienen que el valor real está en entender el dominio del problema y dar forma a los requisitos, no solo en traducir especificaciones a código.
- Hay preocupación por que muchos desarrolladores modernos no tengan una comprensión de pila completa y traten el rendimiento y la robustez como aspectos secundarios.
Entorno de trabajo, escala y reacciones emocionales
- Entornos antiguos: oficinas privadas silenciosas, escritorios grandes, sin notificaciones, gestión técnicamente competente.
- Hoy: interrupciones, reuniones, proliferación de herramientas y sistemas cada vez más interconectados y APIs externas.
- Algunos se sienten inspirados y nostálgicos; otros son escépticos y señalan que la complejidad moderna y las integraciones desordenadas hacen irrealista la perfección “de una sola pasada”.
- Un sentimiento recurrente: muchos desarrolladores sienten que se les infrautiliza, haciendo trabajo CRUD/publicitario de bajo impacto en lugar de sistemas fundamentales, lo que genera frustración y cinismo.