5 audaci mosse nello sviluppo software che tutti hanno definito folli, finché non hanno funzionato
Lo sviluppo software è ricco di framework conosciuti—Agile, a cascata, Scrum—tutte scelte solide che aiutano i team a consegnare nei tempi previsti 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 arrivano spesso quando qualcuno prova qualcosa che, sulla carta, sembra folle. È rischioso, certo, ma di solito è proprio lì che si nascondono le grandi opportunità.
“L’AI è davvero brava a svolgere il 70% del lavoro più velocemente,” afferma Alex Zajac, SDE & AI presso Amazon e creatore della newsletter Hungry Minds. “Ma quell’ultimo 30% è la parte più difficile: portarla in produzione, assicurarsi che non abbia allucinazioni e configurare adeguati controlli di valutazione."
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
In altre parole, uno sviluppo software audace non consiste solo nell’utilizzare nuovi strumenti: significa svolgere il lavoro difficile e poco appariscente necessario per farli funzionare davvero.
La maggior parte delle aziende si attiene al consueto manuale operativo perché viene percepito come “sicuro”. Nessuno viene accusato di aver agito in modo avventato se un’idea non funziona all’interno di un processo standard. Tuttavia, secondo un sondaggio McKinsey del 2023, le aziende che incoraggiano l’assunzione calcolata di rischi hanno una probabilità 1,7 volte maggiore di superare i concorrenti del settore negli indicatori di innovazione.
E anche quando sappiamo che il pensiero audace può dare risultati, è sorprendentemente raro trovare ambienti che ricompensino davvero la sperimentazione. Troppe poche organizzazioni incoraggiano esplicitamente l’assunzione di rischi nei progetti software.
I primi adottanti, o talvolta veri e propri pionieri, spesso riescono a definire le regole prima ancora che tutti gli altri sappiano che esistono.
Nonostante tutta la paura e l’esitazione, esistono team che hanno fatto un salto nel vuoto e sono approdati a qualcosa di brillante. Ecco cinque strategie che inizialmente sembravano insolite—o forse troppo caotiche—per avere successo.
Strategia n. 1: ingegneria del caos (Netflix)
Il "Chaos Monkey" di Netflix interrompe intenzionalmente i sistemi in produzione per testarne la resilienza. Sembra folle, vero? Eppure questo approccio ha aiutato Netflix a mantenere un tempo di attività del 99.99% durante la crescita da 7 milioni a oltre 230 milioni di abbonati.
"Ci siamo resi conto che sperare nella stabilità non era una strategia," ha dichiarato l’ex ingegnere di Netflix Kolton Andrus. "Iniettando regolarmente dei guasti, i nostri team hanno smesso di temere le interruzioni e hanno costruito sistemi più solidi per impostazione predefinita."
L’intuizione chiave era controintuitiva: creare guasti controllati impediva effettivamente quelli catastrofici. I test di iniezione dei guasti di Netflix hanno rivelato debolezze che sarebbero rimaste nascoste fino al verificarsi di una grave interruzione.
Indicazione pratica: iniziate con una "giornata di simulazione" in cui simulate i guasti in un ambiente non di produzione. Scegliete un servizio critico e introducete semplici guasti, come terminare le istanze o interrompere le connessioni di rete. Documentate ciò che si rompe e risolvete queste vulnerabilità prima che causino problemi reali.
Strategia n. 2: distribuzione continua (Flickr)
Nel 2009, quando la maggior parte delle aziende effettuava distribuzioni mensili, la presentazione di Flickr intitolata "10 distribuzioni al giorno" lasciò tutti a bocca aperta. I team temevano che rilasci più piccoli e frequenti avrebbero creato il caos, ma Flickr scoprì l’opposto: rilasci più frequenti riducevano effettivamente il rischio in modo drastico.
La matematica è semplice ma potente: se distribuite 5-10 modifiche alla volta, isolare i problemi è facile. Se distribuite 500 modifiche dopo un mese, buona fortuna nel trovare l’ago in quel pagliaio.
Lotti di distribuzione più piccoli = raggio d’impatto ridotto.
Le aziende che adottano la distribuzione continua segnalano il 70% in meno di guasti in produzione e un ripristino 24 volte più rapido quando si verificano effettivamente dei problemi, secondo il rapporto Stato del DevOps 2023. Da allora questa pratica è diventata uno standard nelle aziende tecnologiche di ogni dimensione.
Indicazione pratica: implementate un approccio basato su una "finestra di distribuzione", in cui i team aumentano gradualmente la frequenza delle distribuzioni. Iniziate passando da distribuzioni mensili a distribuzioni settimanali, poi a due distribuzioni alla settimana, finché non avrete sviluppato l’automazione e la fiducia necessarie per distribuire più volte al giorno. Concentratevi sulla creazione di una solida suite di test che venga eseguita automaticamente prima di ogni distribuzione.
Strategia n. 3: modello completamente da remoto (GitLab)
Prima della pandemia, la struttura completamente da remoto di GitLab sembrava radicale. Eppure ha permesso all’azienda di assumere i migliori talenti a livello globale e ha imposto fin dal primo giorno eccellenti pratiche di documentazione.
Il manuale pubblico di GitLab (ora composto da oltre 15.000 pagine) è diventato la loro arma segreta, eliminando il problema del "Non lo sapevo" che affligge molti team distribuiti. Questo approccio basato innanzitutto sulla documentazione ha permesso ai nuovi assunti di completare più rapidamente l'inserimento e ha reso il processo decisionale più trasparente.
La documentazione si adatta meglio della conoscenza tramandata. Pensate in grande!
"Quando non puoi toccare qualcuno sulla spalla per chiedere informazioni, sei costretto a documentare tutto con chiarezza", spiega Darren Murph, responsabile del lavoro da remoto di GitLab. "Questo crea una resilienza organizzativa che le aziende incentrate sull'ufficio raggiungono raramente."
Indicazione operativa: anche se non lavori completamente da remoto, adotta una pratica di documentazione "orientata innanzitutto al lavoro da remoto". Crea una base di conoscenza centralizzata per tutte le decisioni, i processi e le conoscenze tramandate importanti. Stabilisci la regola che, se qualcosa non è documentato, non esiste. Esamina questa documentazione ogni trimestre per mantenerla aggiornata.
Strategia n. 4: sviluppo basato sul ramo principale (Etsy)
Etsy ha abbandonato le complesse strategie di ramificazione a favore di un modello in cui tutti effettuano frequentemente il commit sul codice principale. Questo approccio ha messo in discussione la convinzione convenzionale secondo cui gli sviluppatori abbiano bisogno di rami di funzionalità isolati per lavorare in modo efficace.
"Abbiamo scoperto che i rami longevi creavano un falso senso di sicurezza", afferma l'ex ingegnere di Etsy Daniel Schauenberg. "In realtà, ritardavano soltanto i problemi di integrazione e creavano conflitti più grandi quando i rami venivano finalmente uniti."
Lo sviluppo basato sul ramo principale ha aiutato Etsy a passare da 50 a oltre 2.000 sviluppatori continuando a effettuare oltre 50 distribuzioni al giorno. L'approccio ha costretto il team a creare test automatizzati migliori, poiché il ramo principale doveva rimanere pulito, ed ha eliminato il fin troppo comune "inferno delle fusioni" che i team affrontano con i rami di funzionalità.
Alex ha osservato uno schema simile parlando di IA e basi di codice ricche di contesto. “Le cose che sono realmente profondamente accoppiate ai vostri sistemi proprietari… richiederanno molte persone,” ha detto.
Negli ambienti in rapida evoluzione, i team che lavorano direttamente nel ramo principale devono comprendere a fondo la progettazione del sistema e i compromessi, perché c'è meno spazio per nascondersi dietro rami longevi. Non si tratta soltanto di effettuare commit più rapidamente; si tratta di avere ingegneri più vicini alla complessità reale.
Indicazione operativa: implementa dei toggle delle funzionalità per nascondere il lavoro in corso mentre effettui commit quotidiani sul ramo principale. Inizia con un piccolo team di fiducia per acquisire sicurezza nell'approccio. Fissa come obiettivo del team effettuare il commit sul ramo principale almeno una volta al giorno e misura nel tempo la riduzione dei problemi di integrazione.
La vostra strategia per i toggle delle funzionalità è davvero importante per ciò che mostrate ai vostri clienti!
More Articles
- I 10 migliori strumenti di sviluppo software recensiti per il 2026
- I 10 migliori software per lo sviluppo di applicazioni nel 2026
- I 10 migliori strumenti di IA per la produttività degli sviluppatori nel 2026
- I 10 migliori software per lo sviluppo di app mobili recensiti per il 2026
- I 10 migliori strumenti di programmazione con IA nel 2026
Strategia n. 5: codice aperto come impostazione predefinita (Hashicorp)
Hashicorp ha costruito un'azienda dal valore di miliardi di dollari rendendo open source i propri strumenti di infrastruttura principali, come Terraform, Vault e Consul. In contrasto con i modelli aziendali software tradizionali, questa strategia ha consentito una rapida adozione e contributi da parte di migliaia di sviluppatori in tutto il mondo.
"Quando abbiamo iniziato, le persone pensavano che fossimo pazzi a regalare il nostro codice migliore", osserva il cofondatore Mitchell Hashimoto. "Ma abbiamo scoperto che un'adozione diffusa crea più valore di quanto si perda in potenziali ricavi dalle licenze."
Per i singoli sviluppatori, la scelta degli strumenti potenziati dall'IA più adatti può seguire una logica simile. Alex ha raccontato di aver scelto recentemente di acquistare Cursor Pro perché “mi capisce, o capisce lo stile con cui sto lavorando.” Proprio come HashiCorp ha puntato sulla fiducia e sulla sintonia con la comunità attraverso il codice aperto, oggi gli ingegneri si orientano verso strumenti che comprendono intuitivamente i loro flussi di lavoro, anche quando questo significa scegliere l'opzione meno diffusa.
Il loro strumento Terraform ha ottenuto oltre 100.000 stelle su GitHub ed è diventato uno standard del settore, un risultato che con un approccio tradizionale a codice chiuso avrebbe richiesto decenni. L'azienda monetizza attraverso funzionalità per le imprese, assistenza e servizi ospitati, mantenendo al contempo il favore di una vasta comunità di sviluppatori.
Indicazione operativa: Individua i componenti del tuo software che potrebbero trarre vantaggio dal coinvolgimento della comunità. Inizia rendendo a codice aperto una libreria o uno strumento utile che non faccia parte della tua proprietà intellettuale principale. Crea un processo di contribuzione che renda facile per gli utenti esterni migliorare il tuo codice e investi in una buona documentazione per facilitarne l'adozione.
Il filo conduttore
Ciò che accomuna queste strategie non è solo l'audacia, ma il rischio calcolato con cicli di riscontro rapidi. Ogni squadra ha creato meccanismi per imparare velocemente dagli errori e correggere la rotta.
Alex ha spiegato come l'IA stia cambiando ciò che significa essere uno sviluppatore. “Non saremo sostituiti,” afferma, “ma la finestra mobile delle responsabilità sta cambiando.”
Secondo alcuni, gli sviluppatori stanno diventando sempre più simili a ingegneri di prodotto; altri prevedono una divisione tra generalisti e specialisti. In ogni caso, le strategie di sviluppo audaci di oggi non hanno successo soltanto grazie a strumenti innovativi: hanno successo quando le squadre sono disposte ad adattare i propri flussi di lavoro, ruoli e modalità di pensiero.
Mentre ripensi alle tue strategie di sviluppo, trovare i partner giusti può fare la differenza. Potresti valutare di collaborare, ad esempio, con un'azienda di sviluppo software personalizzato o con un'azienda di sviluppo software in una regione vicina azienda di sviluppo software in una regione vicina, per esempio.
Iscriviti alla newsletter di The CTO Club per ricevere ulteriori consigli, strumenti e buone pratiche sullo sviluppo software.
