En 1998 recién estaba empezando a construir webs.
En esa época el maquetado se hacía con tablas. Se usaban estilos inline (como hardcodeados en jerga actual) y me pasaba que cuando veía el resultado en el navegador, no quedaba igual a la imagen mental que tenía.
Por esto empecé a usar un editor visual (Macromedia Dreamweaver, hoy de Adobe), quería aprender viendo a un constructor experimentado.
Con esta herramienta podías armar una página web arrastrando elementos y el programa escribía el HTML por vos.
Todo genial... arrastraba, soltaba, y aparecía una página. La pesadilla para mí empezaba cuando borraba un elemento desde la interfaz o me tocaba deshacer alguna acción.
Quedaban etiquetas abiertas, otras mal cerradas, código sucio que después había que limpiar a mano.
Sí, me tomaba esa molestia. Corrigiendo los errores de mi editor autómata, aprendí muchísimo.
En 2001 empecé a escribir webs completas. Pasé por JavaScript (con el que renegábamos todos, porque cada navegador lo interpretaba a su manera), CSS, la llegada del iPhone y la web móvil, y a partir de 2012 incluí PHP, los cPanels y todo el mundo de los servidores.
Ahí entendí que maquetar también era arquitectar: tenía que decidir qué resuelve el servidor, qué resuelve el navegador y qué pasa cuando algo falla.
Pensar la arquitectura se volvía un proceso cada vez más complejo.
Con los años aprendí a reconocer un patrón que se repite con cada herramienta nueva.
En arquitectura de software tiene nombre: ilusión de productividad. Es entregar algo que parece resolver la tarea, pero se queda corto.
La herramienta hace el 80%, y el resto se completa con parches.
Ya pasó con las herramientas CASE de los 90, como Rational Rose, que prometían generar software a partir de diagramas. Después con el low-code y el no-code, como Wix o Bubble: arrastrás, configurás y tenés una web o una app.
Yo lo viví a escala chica con Dreamweaver y hoy, casi 30 años después, pasa con la IA.
Hace poco me encontré con un ensayo de Frederick Brooks, un informático estadounidense que dirigió en IBM el desarrollo de la familia de computadoras System/360 y de su sistema operativo, OS/360, uno de los proyectos de software más grandes de su época.
Ese proyecto se atrasó y costó mucho más de lo previsto. Años después Brooks se preguntó por qué ninguna herramienta nueva resolvía lo difícil del software. Lo respondió en 1986 en No Silver Bullet.
"No hay bala de plata", concluyó (en el folclore, a un hombre lobo se lo mata con una bala de plata). Para Brooks, el software era como un monstruo que se disfraza de proyecto inofensivo y termina devorando plazos y presupuestos.
¿Y por qué no hay bala de plata? Porque una bala de plata sirve contra lo que se puede apuntar y lo difícil del software es que no tiene un solo punto débil.
Su idea: en software hay dos tipos de problemas.
1, los accidentales: codificar, testear, desplegar y
2, los esenciales:
la complejidad del problema,
la conformidad con reglas e interfaces que no elegiste,
la necesidad de cambiar
y la invisibilidad (porque el software no tiene una forma que se pueda ver completa).
En todo este camino de evolución, las herramientas fueron achicando lo accidental. Aunque lo esencial va a seguir en manos de quien diseña.
Lo leo hoy, desde el sector industrial.
Brooks escribía desde sistemas grandes, de esos que tienen que seguir funcionando mientras todo cambia alrededor. Su conclusión fue que los grandes diseños nacen de grandes diseñadores, y que el mayor (y mejor) esfuerzo que podemos hacer es formarlos.
Años después aprendí mucho de esto con la app de una startup.
Un MVP al que se le sumaban features, y un equipo que sumaba programadores para seguirle el ritmo. Más manos para escribir código, pero lo esencial, cómo estaba pensado el producto, no cambiaba.
Con la web de la empresa que conté en El oficio detrás del prompt busqué lo opuesto: una base liviana, simple, para crecer de a poco sin tener que empezar de cero cada vez que se sumaba un nuevo feature.
Un producto que crece necesita más que manos. Necesita que alguien decida qué es esencial.
Y lo esencial no es código.
Hay algo más en esa historia, que tiene que ver con cómo conversa un equipo. Lo cuento en el próximo.
Por eso sigamos creando,
sigamos construyendo,
sigamos buscando que te represente_