Cargo Cult Software Engineering

Nei mari del Sud c’è un culto del carico di persone. Durante la guerra hanno visto aerei con un sacco di buoni materiali, e vogliono che la stessa cosa accada ora. Così si sono organizzati per fare cose come piste, per mettere fuochi lungo i lati delle piste, per fare una capanna di legno per un uomo in cui sedersi, con due pezzi di legno in testa per cuffie e barre di bambù che spuntano come antenne—lui è il controllore—e aspettano che gli aerei atterrino. Stanno facendo tutto bene. La forma è perfetta. Sembra esattamente com’era prima. Ma non funziona. Non atterrano aerei. Quindi chiamo queste cose scienza del culto del carico, perché seguono tutti i precetti e le forme apparenti di indagine scientifica, ma manca qualcosa di essenziale, perché gli aerei non atterrano.
– Richard Feynman

Trovo utile tracciare un contrasto tra due diversi stili di sviluppo organizzativo: “orientato al processo” e “orientato all’impegno”. Lo sviluppo orientato al processo raggiunge la sua efficacia attraverso una pianificazione abile, l’uso di processi accuratamente definiti, l’uso efficiente del tempo disponibile e l’applicazione abile delle migliori pratiche di ingegneria del software. Questo stile di sviluppo ha successo perché l’organizzazione che lo utilizza è in costante miglioramento. Anche se i suoi primi tentativi sono inefficaci, una costante attenzione al processo significa che ogni tentativo successivo funzionerà meglio del tentativo precedente.

Lo sviluppo orientato all’impegno va sotto diversi nomi tra cui” sviluppo orientato agli eroi “e” empowerment individuale.”Le organizzazioni orientate all’impegno sono caratterizzate dall’assunzione delle migliori persone possibili, chiedendo loro un impegno totale nei loro progetti, autorizzandoli con un’autonomia quasi completa, motivandoli in misura estrema e poi vedendo che lavorano 60, 80 o 100 ore alla settimana fino al termine del progetto. Lo sviluppo orientato all’impegno deriva la sua potenza dalla sua enorme capacità motivazionale-studio dopo studio ha scoperto che la motivazione individuale è di gran lunga il più grande singolo contributore alla produttività. Gli sviluppatori fanno volontari, impegni personali per i progetti su cui lavorano, e spesso vanno a lunghezze straordinarie per rendere i loro progetti hanno successo.

Impostori organizzativi

Se usato in modo consapevole, uno stile di sviluppo può produrre software di alta qualità in modo economico e rapido. Ma entrambi gli stili di sviluppo hanno sosia patologiche che non funzionano quasi bene, e che può essere difficile da distinguere dagli articoli genuini.

L’organizzazione impostore del processo basa le sue pratiche su una devozione servile al processo per il bene del processo. Queste organizzazioni guardano organizzazioni orientate ai processi come il Software Engineering Laboratory della NASA e l’ex divisione Federal Systems di IBM. Osservano che quelle organizzazioni generano molti documenti e tengono frequenti riunioni. Essi concludono che, se generano un numero equivalente di documenti e tengono un numero comparabile di riunioni, avranno lo stesso successo. Se generano più documentazione e tengono più riunioni, avranno ancora più successo! Ma non capiscono che la documentazione e le riunioni non sono responsabili del successo; sono gli effetti collaterali di alcuni specifici processi efficaci. Chiamiamo queste organizzazioni burocratiche perché mettono la forma dei processi software al di sopra della sostanza. Il loro uso improprio del processo è demotivante, il che danneggia la produttività. E non sono molto piacevoli da lavorare.

L’organizzazione commitment-imposter si concentra principalmente sulla motivazione delle persone a lavorare per lunghe ore. Queste organizzazioni guardano aziende di successo come Microsoft; osservano che generano pochissima documentazione; offrono stock option ai loro dipendenti; e poi richiedere loro di lavorare montagne di straordinari. Concludono che se anche loro minimizzano la documentazione, offrono stock option e richiedono straordinari estesi, avranno successo. Meno documentazione e più straordinari, meglio è! Ma a queste organizzazioni manca il fatto che Microsoft e altre aziende orientate all’impegno di successo non richiedono straordinari. Assumono persone che amano creare software. Essi squadra queste persone con altre persone che amano creare software tanto quanto fanno. Essi forniscono sontuoso supporto organizzativo e ricompense per la creazione di software. E poi li liberano. Il risultato naturale è che gli sviluppatori di software e manager scelgono di lavorare lunghe ore volontariamente. Le organizzazioni impostore confondono l’effetto (lunghe ore) con la causa (alta motivazione). Noi chiamiamo le organizzazioni impostore sweatshops perché sottolineano lavorare sodo piuttosto che lavorare in modo intelligente, e tendono ad essere caotico e inefficace. Non sono molto piacevoli da lavorare per entrambi.

Cargo Cult Software Engineering

A prima vista, questi due tipi di organizzazioni impostore sembrano essere esattamente opposti. Uno è incredibilmente burocratico, e l’altro è incredibilmente caotico. Ma una somiglianza chiave è in realtà più importante delle loro differenze superficiali. Nessuno dei due è molto efficace, e la ragione è che nessuno dei due capisce ciò che rende davvero i suoi progetti avere successo o fallire. Passano attraverso i movimenti di guardare come organizzazioni efficaci che sono stilisticamente simili. Ma senza alcuna reale comprensione del perché le pratiche funzionano, sono essenzialmente solo attaccare pezzi di bambù nelle orecchie e sperando che i loro progetti atterreranno in modo sicuro. Molti dei loro progetti finiscono per schiantarsi perché questi sono solo due diverse varietà di ingegneria del software di culto del carico, simili nella loro mancanza di comprensione di ciò che rende i progetti software funzionano.

Cargo cult software engineering è facile da identificare. Gli ingegneri del software Cargo cult giustificano le loro pratiche dicendo: “L’abbiamo sempre fatto in questo modo in passato” o “i nostri standard aziendali ci richiedono di farlo in questo modo”, anche quando questi modi non hanno senso. Si rifiutano di riconoscere i compromessi coinvolti nello sviluppo orientato ai processi o orientato all’impegno. Entrambi hanno punti di forza e di debolezza. Quando vengono presentate nuove pratiche più efficaci, gli ingegneri del software cargo cult preferiscono rimanere nelle loro capanne di legno con abitudini di lavoro familiari, confortevoli e non necessariamente efficaci. “Fare la stessa cosa ancora e ancora e aspettarsi risultati diversi è un segno di follia”, dice il vecchio proverbio. È anche un segno di ingegneria del software di culto del carico.

Il vero dibattito

In questa rivista e in molte altre pubblicazioni, passiamo il nostro tempo a discutere se il processo è buono o l’empowerment individuale (in altre parole, lo sviluppo orientato all’impegno) potrebbe essere migliore. Questa è una falsa dicotomia. Il processo è buono, così come l’empowerment individuale. I due possono esistere fianco a fianco. Le organizzazioni orientate al processo possono richiedere un impegno estremo su progetti specifici. Le organizzazioni orientate all’impegno possono utilizzare abilmente le pratiche di ingegneria del software.

La differenza tra questi due approcci si riduce davvero alle differenze di stile e personalità. Ho lavorato su diversi progetti di ogni stile e mi sono piaciute cose diverse su ogni stile. Alcuni sviluppatori si divertono a lavorare metodicamente su un programma da 8 a 5, che è più comune nelle aziende orientate al processo. Altri sviluppatori godono della messa a fuoco e l’eccitazione che viene fornito con fare un 24×7 impegno per un progetto. I progetti orientati all’impegno sono in media più eccitanti, ma un progetto orientato al processo può essere altrettanto eccitante quando ha una missione ben definita e stimolante. Le organizzazioni orientate ai processi sembrano degenerare nei loro sosia patologici meno spesso di quanto facciano le organizzazioni orientate all’impegno, ma entrambi gli stili possono funzionare bene se sono abilmente pianificati ed eseguiti.

Il fatto che sia i progetti orientati al processo che quelli orientati all’impegno abbiano sosia patologici ha infangato il dibattito. Alcuni progetti condotti in ogni stile hanno successo e alcuni falliscono. Ciò consente a un avvocato del processo di indicare il successo del processo e gli errori di impegno e affermare che il processo è la chiave del successo. Permette all’avvocato dell’impegno di fare la stessa cosa.

Il problema che è caduto nel dimenticatoio mentre discutevamo di processo contro impegno è così palese che, come la lettera di Edgar Allen Poe, potrebbe essere stato semplicemente così ovvio che l’abbiamo trascurato. Non dovremmo discutere di processo contro impegno; dovremmo discutere di competenza contro incompetenza. La vera differenza non è quale stile viene scelto, ma quale istruzione, formazione e comprensione viene portata al progetto. Piuttosto che discutere processo vs impegno, dovremmo essere alla ricerca di modi per aumentare il livello medio di sviluppatore e manager competenza. Ciò migliorerà le nostre possibilità di successo indipendentemente dallo stile di sviluppo che scegliamo.