Idea principal

El software vivió una época en la que unos analistas especificaban y unos programadores producían código al peso. Unos pensaban, otros ejecutaban. Esa separación ha desaparecido: hoy un desarrollador toma un problema de principio a fin — arquitectura, código, seguridad, entrega, seguimiento — e incluso los arquitectos separados del resto del equipo escasean cada vez más.

Nadie pide el regreso de los analistas-programadores, y nadie sostiene que se escribiera mejor software cuando la reflexión y la ejecución vivían en dos cabezas distintas. La profesión lo zanjó por el uso, sin teoría.

Ese precedente tiene valor de argumento: la misma línea de corte, desplazada del código al producto, debe explicar por qué escaparía a la suerte de la anterior. La carga de la prueba cambia de bando.

Por qué es importante

Convierte una opinión sobre la organización de producto en una pregunta histórica verificable: la separación entre diseño y ejecución ya se probó a gran escala en el mismo sector, y fue abandonada.

También aporta una trayectoria probable en lugar de un simple desacuerdo: los repartos de este tipo retroceden cuando el utillaje reduce el coste de hacer ambas cosas.

Matices y límites

Un precedente no es una prueba. El desarrollo tuvo sus propias razones para volver a coser las dos mitades — ciclos cortos, integración continua, coste de la marcha atrás — y nada garantiza que esas razones se trasladen al producto.

Y el abandono no fue total: subsisten roles de arquitecto, staff engineer o tech lead, con una parte de diseño distinta de la ejecución. Lo que desapareció fue la correa de transmisión, no toda especialización.

Preguntas abiertas

• ¿Qué condiciones técnicas permitieron realmente volver a coser diseño y ejecución en desarrollo, y cuáles existen hoy en producto?