Divario sull’ingegneria del software: app del weekend vs software enterprise

Una demo costruita in pochi giorni entusiasma la platea. Mostra che “gira” e fa chiedere perché i team non vadano dieci volte più veloci. Non regge però requisiti come sicurezza, affidabilità, integrazioni e governance. È il punto del saggio “Citizens Build, Agents Execute, Experts Govern” su martinfowler.com¹.

L’autrice descrive una scena ricorrente negli ultimi sei mesi: una persona non tecnica porta una demo fatta in fretta, collega il risultato al potenziale dell’IA e confronta quel ritmo con quello dei team di ingegneria¹. Dodici mesi fa quella prova sarebbe stata improbabile; oggi è alla portata. Da qui nasce l’aspettativa che tutto il software si possa costruire con la stessa rapidità¹.

Il saggio non sminuisce chi sperimenta. Chiarisce il fraintendimento: ciò che funziona in condizioni controllate non equivale a un sistema destinato a durare. Un prototipo mostra una funzionalità. Un prodotto regge incidenti, carico, cambi di requisito, audit, on-call, e convive con altri sistemi. È lo scarto tra “far girare qualcosa” e “fare ingegneria del software”¹.

La conversazione spesso confronta cose impari: tempi e feature visibili del prototipo da un lato; complessità invisibili dei sistemi enterprise dall’altro. L’autrice evita il tono paternalista del “non sapete cosa serve” e propone un linguaggio che riconosce il valore della scoperta senza confonderla con la consegna in produzione¹. La comunità, ammette, ha contribuito al fraintendimento: ha mostrato demo brillanti senza dire cosa manca per farne prodotti solidi¹.

La traccia è nel titolo: “citizens build, agents execute, experts govern”¹. Chi prova può costruire. Strumenti automatizzati possono eseguire. Servono esperti che governano scelte, qualità e responsabilità. La distinzione non spegne le demo: le colloca. E impedisce che il prototipo diventi la misura del lavoro dei team enterprise¹.

Ridurre il divario non significa frenare l’innovazione dal basso. Significa incanalarla. Una demo valida un’idea, fa emergere requisiti, accelera una decisione. Da lì parte un altro mestiere: tenere insieme vincoli organizzativi, rischio, manutenzione, osservabilità, evoluzione nel tempo¹.

Quando arriva la prossima demo “del weekend”, la domanda utile cambia. Non “perché non andiamo dieci volte più veloci?”, ma “a che stadio siamo e chi fa cosa adesso?”. Chi costruisce per esplorare. Cosa possono eseguire gli strumenti. Chi governa qualità e responsabilità. Spostare il confronto su questi tre piani mette energia dove serve e chiarisce le aspettative verso i team di ingegneria¹.

Un effetto collaterale desiderabile: se la discussione adotta questi piani, le demo migliorano. Non puntano solo a stupire, ma a raccogliere i dati necessari al passaggio di consegne. Anche questo, scrive il saggio, è un lavoro di ingegneria: decidere cosa non costruire adesso per poter costruire bene domani¹.