Idea principale

Il software ha conosciuto un'epoca in cui gli analisti scrivevano le specifiche e i programmatori producevano codice a metro. Gli uni pensavano, gli altri eseguivano. Quella separazione è sparita: oggi uno sviluppatore prende un problema dall'inizio alla fine — architettura, codice, sicurezza, consegna, monitoraggio — e perfino gli architetti separati dal resto del team si fanno sempre più rari.

Nessuno chiede il ritorno degli analisti-programmatori, e nessuno sostiene che si scrivesse software migliore quando la riflessione e l'esecuzione vivevano in due teste diverse. Il mestiere ha deciso con la pratica, senza teoria.

Questo precedente vale come argomento: la stessa linea di demarcazione, spostata dal codice al prodotto, deve spiegare perché sfuggirebbe alla sorte della precedente. L'onere della prova cambia campo.

Perché è importante

Trasforma un'opinione sull'organizzazione di prodotto in una questione storica verificabile: la separazione tra progettazione ed esecuzione è già stata sperimentata su larga scala nello stesso settore, ed è stata abbandonata.

Offre anche una traiettoria probabile, invece di un semplice disaccordo: le separazioni di questo tipo arretrano quando gli strumenti riducono il costo di fare entrambe le cose.

Sfumature e limiti

Un precedente non è una prova. Lo sviluppo aveva ragioni proprie per ricucire le due metà — cicli brevi, integrazione continua, costo del rollback — e niente garantisce che queste ragioni valgano anche per il prodotto.

E l'abbandono non è stato totale: ruoli di architetto, di staff engineer o di tech lead sopravvivono, con una parte di progettazione distinta dall'esecuzione. Quello che è sparito è la cinghia di trasmissione, non ogni forma di specializzazione.

Domande aperte

• Che cosa, lato prodotto, avrebbe il ruolo che il costo del rollback ha avuto lato sviluppo?