5 Mosse Audaci nello Sviluppo Software Che Tutti Ritenevano Folli—Finché Non Hanno Funzionato
Lo sviluppo software è pieno di framework familiari—Agile, Waterfall, Scrum—tutte scelte solide che aiutano i team a consegnare puntualmente e con meno sorprese.
Ma a volte ci sentiamo così a nostro agio nel seguire questi percorsi già battuti che dimentichiamo che le vere svolte spesso arrivano quando qualcuno prova qualcosa che sembra folle sulla carta. È rischioso, certo, ma spesso è lì che si nascondono le grandi vittorie.
“L’IA è davvero brava a fare il 70% del lavoro più in fretta,” afferma Alex Zajac, SDE & AI in Amazon e creatore della newsletter Hungry Minds. “Ma quell’ultimo 30% è il più difficile—portare in produzione, assicurarsi che non ‘fantastichi’, e impostare le barriere di valutazione."
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
In altre parole, lo sviluppo software audace non riguarda solo l’uso di nuovi strumenti—si tratta di fare il lavoro duro e poco glamour di farli funzionare davvero.
La maggior parte delle aziende si attiene allo schema tradizionale perché è percepito come “sicuro.” Nessuno viene accusato di essersi comportato da ribelle se un’idea non funziona secondo un processo standard. Tuttavia, secondo un sondaggio McKinsey del 2023, le aziende che incoraggiano la presa di rischi calcolati hanno 1,7 volte più probabilità di superare i concorrenti del settore nei parametri di innovazione.
E anche quando sappiamo che un pensiero audace può dare i suoi frutti, è sorprendentemente raro trovare ambienti che premiano davvero la sperimentazione. Poche organizzazioni incoraggiano esplicitamente la presa di rischi nei progetti software.
I primi adottanti, o a volte veri pionieri, spesso hanno l’opportunità di definire le regole prima che tutti gli altri sappiano che esistono.
Nonostante tutte le paure e le esitazioni, ci sono team là fuori che hanno fatto un salto nel vuoto e sono atterrati su qualcosa di brillante. Ecco cinque strategie che inizialmente sembravano strane—o forse troppo caotiche—per avere successo.
Strategia #1: Chaos Engineering (Netflix)
Il “Chaos Monkey” di Netflix rompe intenzionalmente i sistemi in produzione per testarne la resilienza. Sembra una follia, vero? Eppure questo approccio ha aiutato Netflix a mantenere il 99,99% di uptime, mentre passava da 7 milioni a oltre 230 milioni di abbonati.
"Ci siamo resi conto che sperare nella stabilità non era una strategia," ha detto l’ex ingegnere Netflix Kolton Andrus. "Iniettando errori regolarmente, i nostri team hanno smesso di temere i malfunzionamenti e hanno costruito sistemi più robusti per impostazione predefinita."
La vera intuizione è stata controintuitiva: creare guasti controllati ha effettivamente prevenuto quelli catastrofici. I test di iniezione di errori di Netflix hanno rivelato debolezze che sarebbero rimaste nascoste fino al verificarsi di un grande blackout.
Consiglio pratico: Parti da un “Game Day” in cui simuli i guasti in un ambiente non di produzione. Scegli un servizio critico e introduci errori semplici come spegnere istanze o interrompere connessioni di rete. Documenta cosa si rompe e risolvi quelle vulnerabilità prima che causino problemi reali.
Strategia #2: Continuous Deployment (Flickr)
Nel 2009, quando la maggior parte delle aziende effettuava i deploy una volta al mese, la presentazione di Flickr "10 deploy al giorno" ha lasciato tutti a bocca aperta. I team erano preoccupati che rilasci più piccoli e frequenti avrebbero creato caos, ma Flickr ha scoperto l’opposto: i rilasci frequenti hanno ridotto notevolmente il rischio.
Il ragionamento è semplice ma efficace: se fai il deploy di 5-10 modifiche alla volta, isolare i problemi è immediato. Se fai il deploy di 500 modifiche dopo un mese, buona fortuna a trovare l’ago nel pagliaio.
Batch più piccoli di deployment = minor raggio di impatto.
Le aziende che adottano il CD dichiarano il 70% in meno di errori in produzione e una capacità di recupero 24 volte più veloce quando si verificano problemi, secondo il rapporto State of DevOps 2023. Questa pratica è ormai standard nelle aziende tech di tutte le dimensioni.
Consiglio pratico: Implementa un approccio “deploy window” in cui i team aumentano gradualmente la frequenza dei deployment. Inizia passando da un deploy mensile a uno settimanale, poi due volte a settimana, fino a costruire l’automazione e la sicurezza necessarie per deploy multipli al giorno. Concentrati su una suite di test robusta che venga eseguita automaticamente prima di ogni deployment.
Strategia #3: Modello interamente remoto (GitLab)
Prima della pandemia, la struttura completamente remota di GitLab sembrava radicale. Eppure ha permesso loro di assumere i migliori talenti in tutto il mondo e ha imposto eccellenti pratiche di documentazione sin dal primo giorno.
Il manuale pubblico di GitLab (ora oltre 15.000 pagine) è diventato la loro arma segreta, eliminando il problema del “Non lo sapevo” che affligge molti team distribuiti. Questo approccio alla documentazione come primo passo ha consentito ai nuovi assunti di orientarsi più velocemente e ha reso il processo decisionale più trasparente.
La documentazione si scala meglio della conoscenza tribale. Pensa in grande!
“Quando non puoi bussare sulla spalla di qualcuno per avere informazioni, sei costretto a documentare tutto chiaramente,” spiega Darren Murph, Head of Remote di GitLab. “Questo crea una resilienza organizzativa che le aziende incentrate sull’ufficio raramente raggiungono.”
Consiglio pratico: Anche se non lavori completamente da remoto, adotta una prassi di documentazione "remote-first". Crea una base di conoscenza centralizzata per tutte le decisioni, i processi e le conoscenze tribali importanti. Stabilisci la regola che, se qualcosa non è documentato, non esiste. Rivedi questa documentazione trimestralmente per mantenerla aggiornata.
Strategia #4: Sviluppo Basato su Trunk (Etsy)
Etsy ha abbandonato le strategie complesse di branching a favore di un modello in cui tutti effettuano commit frequentemente sulla base del codice principale. Questo approccio ha sfidato la convinzione comune che gli sviluppatori abbiano bisogno di branch isolati delle feature per lavorare in modo efficace.
“Abbiamo scoperto che i branch di lunga durata creavano un falso senso di sicurezza,” afferma l’ex ingegnere di Etsy Daniel Schauenberg. “In realtà, posticipavano solo il dolore dell’integrazione e generavano conflitti maggiori quando finalmente si univano i rami.”
Lo sviluppo basato su trunk ha aiutato Etsy a passare da 50 a oltre 2.000 sviluppatori, continuando a rilasciare più di 50 volte al giorno. Questo approccio ha obbligato il team a costruire sistemi di test automatici migliori, poiché il branch principale doveva restare pulito, ed ha eliminato il troppo frequente "merge hell" che i team affrontano con i branch delle feature.
Alex ha notato un pattern simile parlando di IA e codebase molto complesse. “Le cose che sono davvero profondamente collegate ai tuoi sistemi proprietari... richiederanno molti umani,” ha detto.
In ambienti ad alta velocità, i team che lavorano direttamente sul trunk devono comprendere a fondo design dei sistemi e compromessi—perché c’è meno spazio per nascondersi dietro branch di lunga durata. Non si tratta solo di fare commit più rapidamente: gli ingegneri sono più vicini alla reale complessità.
Consiglio pratico: Implementa dei feature toggle per nascondere il lavoro in corso mentre effettui commit quotidiani sul branch principale. Inizia con un team ristretto e fidato per costruire confidenza nell’approccio. Stabilisci l’obiettivo di fare commit almeno una volta al giorno sul branch principale e misura la riduzione dei problemi di integrazione nel tempo.
La tua strategia per il feature toggling è davvero importante per ciò che mostri ai clienti!
Strategia #5: Open Source di Default (Hashicorp)
Hashicorp ha costruito un'azienda da miliardi di dollari rendendo open source i loro principali strumenti di infrastruttura come Terraform, Vault e Consul. Contrariamente ai tradizionali modelli di business software, questa strategia ha consentito un’adozione rapida e contributi da migliaia di sviluppatori in tutto il mondo.
“All’inizio, la gente pensava fossimo pazzi a regalare il nostro codice migliore,” osserva Mitchell Hashimoto, co-fondatore. “Ma abbiamo scoperto che un’adozione diffusa crea più valore di quanto si perda potenzialmente dalle licenze.”
Per i singoli sviluppatori, la scelta dei giusti strumenti potenziati con IA può seguire una logica simile. Alex ha condiviso che di recente ha scelto di acquistare Cursor Pro perché “sente cosa mi serve o si adatta allo stile con cui lavoro.” Così come HashiCorp ha puntato sulla fiducia e sull’allineamento con la community nell’open source, ora gli ingegneri si orientano verso strumenti che comprendono intuitivamente il loro workflow—anche se ciò significa scegliere l’opzione meno tradizionale.
Il loro strumento Terraform ha raccolto oltre 100.000 stelle su GitHub ed è diventato uno standard industriale—qualcosa che avrebbe richiesto decenni con un approccio tradizionale closed-source. L’azienda monetizza attraverso funzionalità enterprise, supporto e servizi ospitati, mantenendo però una grande community di sviluppatori.
Conclusione praticabile: Identifica le componenti del tuo software che potrebbero beneficiare dal coinvolgimento della community. Inizia pubblicando come open source una libreria o uno strumento utile che non rappresenta la tua IP principale. Crea un processo di contribuzione che renda semplice per gli esterni migliorare il tuo codice e investi in una buona documentazione per facilitarne l'adozione.
Il filo conduttore
Ciò che collega queste strategie non è solo l'audacia, ma il rischio calcolato con cicli di feedback stretti. Ogni team ha costruito dei meccanismi per imparare rapidamente dagli errori e correggere la rotta.
Alex ha menzionato come l'IA stia cambiando ciò che significa essere uno sviluppatore. “Non stiamo per essere sostituiti,” dice, “ma la finestra mobile delle responsabilità si sta spostando.”
Alcuni dicono che gli sviluppatori stanno diventando sempre più simili a ingegneri di prodotto; altri prevedono una biforcazione tra generalisti e specialisti. In ogni caso, oggi le strategie di sviluppo audaci non hanno successo solo grazie a strumenti innovativi—hanno successo quando i team sono disposti ad adattare i propri flussi di lavoro, ruoli e modo di pensare.
Nel ripensare le tue strategie di sviluppo, trovare i partner giusti può fare la differenza. Potresti valutare di collaborare con una azienda di sviluppo software su misura oppure una azienda di sviluppo software nearshore, per esempio.
Iscriviti alla newsletter di The CTO Club per ulteriori consigli, strumenti e best practice sullo sviluppo software.
