L'arte della guerra applicata allo sviluppo del software

Se lavori nel settore del software, è probabile che tu abbia sentito parlare del paradigma del design divide et impera , che consiste sostanzialmente nel dividere ricorsivamente un problema in due o più sottoproblemi ( divide ), fino a quando questi diventano abbastanza semplici da poter essere risolti direttamente ( conquistare ).

Quello che forse non sapete è che questo paradigma trae origine da un'antica strategia politica (il nome deriva dal detto latino divide et impera ) che suggerisce che è possibile mantenere il controllo sui propri subordinati o sudditi favorendo il dissenso tra di loro.

Questa strategia è stata utilizzata da innumerevoli politici e capi militari nel corso della storia, come Giulio Cesare (che l'ha usata durante le guerre galliche per sconfiggere i Galli militarmente forti) e Napoleone (l'esperto di artiglieria francese avrebbe diviso le truppe nemiche in modo che nessuna parte fosse più forte rispetto alle sue stesse truppe, e quindi interrompere le loro comunicazioni, impedendo gli sforzi del nemico per coordinare ed eseguire attacchi).

L'arte della guerra: antichi principi applicati allo sviluppo

Tuttavia, la regola del divide et impera non è l'unica strategia politica che può essere applicata allo sviluppo del software. Sebbene la politica e la guerra abbiano poco a che fare con lo sviluppo del software, proprio come politici e generali, gli sviluppatori devono guidare i subordinati, coordinare gli sforzi tra i team, trovare le migliori strategie per risolvere i problemi e amministrare le risorse.

L'arte della guerra è un antico trattato militare scritto nel V secolo aC e attribuito a Sun Tzu, un antico stratega militare cinese, le cui teorie hanno avuto una profonda influenza sia sulla filosofia orientale che su quella occidentale.

Nonostante la sua età, il testo è ancora incluso nel programma di molte scuole militari dell'Asia orientale ed è elencato come lettura consigliata in alcune accademie militari occidentali. Il testo è suddiviso in 13 capitoli, ognuno dedicato a un diverso aspetto della guerra.

Tuttavia, oltre alla guerra, i principi e gli insegnamenti di Sun Tzu hanno applicazioni pratiche in politica, affari, sport e, che tu ci creda o no, nello sviluppo di software. In effetti, potresti semplicemente applicare alcuni di questi principi nella tua routine quotidiana, senza nemmeno conoscerne l'origine.

In dettaglio di seguito, troverai un breve elenco di tattiche di base e suggerimenti spiegati in Art of War. Probabilmente possono essere applicati al tuo lavoro nell'industria del software o in qualsiasi altro settore.

Il tempo è fondamentale in qualsiasi campagna

Capo II, paragrafo 2

Quando ti impegnerai in un combattimento vero e proprio, se la vittoria tarda ad arrivare, le armi degli uomini diventeranno opache e il loro ardore sarà smorzato.

Questo principio può essere applicato allo sviluppo del software, descrivendo di norma la relazione tra la durata dei cicli di sviluppo e il morale dello sviluppatore.

Se un gruppo di sviluppatori lavora agli stessi progetti per mesi, senza obiettivi chiari o fine in vista, potrebbe sentirsi frustrato e la sua produttività potrebbe diminuire.

Lo sviluppo del software è uno sforzo intellettuale, quindi la motivazione è il principale carburante per la produttività. Lavorare ogni giorno senza accorgersi che il proprio lavoro sta generando risultati reali può essere molto demotivante.

Come indicato in alcune metodologie agili, la roadmap di sviluppo dovrebbe essere suddivisa in diversi obiettivi e pietre miliari, che il team potrebbe essere in grado di raggiungere in tempi brevi e daranno loro un senso di progresso e realizzazione.

Capo II, paragrafo 18

In guerra, quindi, che il tuo grande obiettivo sia la vittoria, non lunghe campagne.

Questa frase può essere interpretata in due modi:

In primo luogo, può essere visto come un precursore della filosofia UNIX: scrivere programmi che fanno una cosa e la fanno bene . Quando si sviluppa un software, è necessario tenere sempre presente l'obiettivo principale del programma, la funzionalità chiave che fornisce o il problema più grande che risolve e garantire la corretta implementazione.

A volte potresti trarre ispirazione e pensare a una funzionalità davvero interessante da aggiungere, ma non dimenticare che le applicazioni che hanno molte funzionalità utilizzate di rado hanno un nome denigratorio: bloatware .

In secondo luogo, l'affermazione può anche essere considerata un precursore di uno dei principi di sviluppo software snello: fornire il più velocemente possibile .

Prima fornisci il software senza grossi difetti, prima riceverai feedback dal cliente e sarai in grado di incorporare le modifiche nell'iterazione successiva.

Se invece fornisci software non funzionante, perderai un feedback prezioso, perché i clienti non avranno la possibilità di testarlo correttamente. Ciò renderà la fase successiva dello sviluppo più difficile o impossibile nelle situazioni in cui la tua prossima iterazione dipende dal feedback dei clienti.

Nessuna leadership, nessun risultato

Capo III, paragrafo 11

Ora il generale è il baluardo dello Stato; se il baluardo è completo in tutti i punti, lo Stato sarà forte; se il baluardo è difettoso, lo Stato sarà debole.

Questa citazione descrive l'importanza del ruolo del manager in un team di sviluppo: il successo di un progetto dipende dalla forza di tutte le persone coinvolte e il manager è il baluardo del progetto. La responsabilità inizia dall'alto.

Anche se gli sviluppatori lavorano spesso da soli (ciascuno seduto dietro un computer, con comunicazioni limitate con i colleghi), ciò non significa che non abbiano bisogno di una buona leadership. I project manager hanno il compito di mantenere il team in carreggiata, garantire una comunicazione efficace e la risoluzione delle controversie, e i leader, ovviamente, definiscono le priorità del progetto (tra le altre attività), quindi il loro ruolo non deve essere sottovalutato. Né dovrebbe la loro responsabilità se qualcosa va storto. Immagina cosa accadrebbe a un capo militare la cui unità non ha svolto il suo dovere sul campo di battaglia?

Un team può produrre un ottimo software anche se ha alcune mele marce nelle posizioni di sviluppo, ma è improbabile che ciò accada se il project manager è la mela marcia , indipendentemente dal numero di sviluppatori rockstar del team.

Capo VI, paragrafo 28

Non ripetere le tattiche che ti hanno procurato una vittoria, ma lascia che i tuoi metodi siano regolati dall'infinita varietà delle circostanze.

A volte, quando si avvia un progetto, si è tentati di utilizzare lo stesso insieme di tecnologie che abbiamo utilizzato in progetti di successo in precedenza (lo stesso linguaggio di programmazione, le stesse librerie, lo stesso server, ecc.). Tuttavia, a meno che i requisiti dei nuovi progetti non siano esattamente gli stessi di quelli precedenti, questo potrebbe essere l'approccio sbagliato.

Nella programmazione, come nella maggior parte dei domini, la panacea (un presunto rimedio in grado di curare tutte le malattie) non esiste. Non esiste un'unica combinazione di tecnologie che puoi utilizzare per risolvere tutti i problemi; ogni tecnologia ha i suoi vantaggi e svantaggi.

Naturalmente, l'apprendimento di un nuovo linguaggio di programmazione o l'utilizzo di un'API sconosciuta potrebbe inizialmente essere costoso, ma a lungo termine la qualità del software sarà superiore e diventerai uno sviluppatore migliore.

Capo XIII, paragrafo 27

Quindi è solo il sovrano illuminato e il saggio generale che useranno la più alta intelligenza dell'esercito per scopi di spionaggio, e quindi ottengono grandi risultati. Le spie sono un elemento importantissimo in guerra, perché da esse dipende la capacità di movimento di un esercito.

Questa frase può essere interpretata come l'importanza di utilizzare strumenti di monitoraggio e librerie di registrazione durante la fase di manutenzione.

Anche se a volte i clienti potrebbero non pensarlo, lo sviluppo non finisce quando ottieni una versione stabile e completamente testata. Il software è in continua evoluzione, correggendo bug, aggiungendo nuove funzionalità o migliorando l'efficienza.

E non c'è migliore fonte di informazioni per sapere quali modifiche apportare che avere spie che monitorano il software negli ambienti di produzione, controllando quali funzionalità vengono utilizzate di più, gli errori più comuni e le operazioni più lunghe.

Segnalazioni di errori, voci di registrazione e dati di utilizzo sono fondamentali per rilevare bug, identificare colli di bottiglia e altri problemi poiché non è sempre possibile riprodurre le stesse condizioni in ambienti di test controllati.

Lavoro di squadra e motivazione

Capo X, paragrafo 24

Colui che avanza senza cercare fama, Che si ritira senza sfuggire alla colpa, Colui il cui unico scopo è proteggere il suo popolo e servire il suo signore, L'uomo è un gioiello del Regno.

Fondamentalmente, questa è l'antica versione cinese di "non c'è io in squadra" . È più importante lavorare insieme con gli altri piuttosto che perseguire un guadagno personale.

Lo sviluppo del software è un'attività complessa che richiede agli sviluppatori di lavorare in modo efficace come una squadra. Un buon sviluppatore non è colui che risolve il maggior numero di bug, implementa il maggior numero di funzionalità o termina gli incarichi prima del previsto; un buon sviluppatore è colui che aiuta il team a raggiungere i suoi obiettivi.

Reclamare il merito per tutto ciò che hai fatto, non riconoscere i tuoi errori o incolpare gli altri per loro, o definirti un ninja del codice potrebbe ingannare alcuni manager inesperti e potrebbe persino farti guadagnare un aumento, ma diventerai un membro controproducente della tua squadra.

Capo VII, paragrafo 21

Rifletti e rifletti prima di fare una mossa.

Questa frase indica l'importanza delle riunioni di sviluppo del team, come quelle proposte dalle metodologie agili.

Quando si lavora in un team, è importante discutere eventuali modifiche importanti prima di implementarle. Non importa se sei il capo squadra, o se sei la persona con più esperienza in materia, dovresti sempre parlare con, o almeno informare, il resto della squadra.

Ricorda che altri sviluppatori potrebbero darti informazioni su parti sconosciute del software. Ciò significa che potrebbero iniziare a implementare le modifiche più velocemente del previsto, perché potrebbero essere pienamente consapevoli degli effetti di tali modifiche.

Capo X, paragrafo 25

Considera i tuoi soldati come i tuoi figli, e ti seguiranno nelle valli più profonde; considerali come i tuoi diletti figli, ed essi ti staranno accanto fino alla morte.

Questa citazione indica l'importanza della motivazione, un principio di gestione che a volte viene dimenticato da manager e team leader. Gli sviluppatori motivati ​​scriveranno codice migliore, lavoreranno più velocemente, commetteranno meno errori e saranno più disposti a dedicare ore extra.

La motivazione deve essere generata dai manager, interessandosi sinceramente ai propri subordinati, ascoltandoli, curando il loro equilibrio tra lavoro e vita privata, costruendo ambienti di lavoro positivi e curando i loro percorsi di carriera.

Inoltre, non dovresti confondere la motivazione con la remunerazione. Studi recenti dimostrano che il denaro non motiva la maggior parte dei lavoratori, il denaro serve principalmente ad attrarre e trattenere i dipendenti, ma non a renderli felici del proprio lavoro. Quindi aumenti e promozioni non dovrebbero essere visti come strumenti motivazionali.

Pensare fuori dagli schemi

Capo V, paragrafi 7, 8 e 9

Non ci sono più di cinque note musicali, eppure le combinazioni di queste cinque danno origine a più melodie di quante se ne possano mai sentire.

Non ci sono più di cinque colori primari, ma in combinazione producono più sfumature di quante se ne possano mai vedere.

Non ci sono più di cinque gusti cardinali, ma le loro combinazioni producono più sapori di quanti ne possano mai essere assaporati.

Uno degli aspetti positivi della programmazione è che le possibilità sono infinite; puoi sviluppare praticamente dove vuoi (almeno, purché non sia un problema NP-completo).

App mobili, siti Web, giochi, applicazioni desktop... se conosci la programmazione, sono tutti alla tua portata.

Capo III, paragrafo 1

Nell'arte pratica della guerra, la cosa migliore di tutte è prendere il paese del nemico intero e intatto; frantumarlo e distruggerlo non è così buono. Così, anche, è meglio catturare un intero esercito che distruggerlo, catturare un reggimento, un distaccamento o una compagnia intera piuttosto che distruggerli.

Quando si lavora su un progetto con una base di codice di grandi dimensioni, è comune trovare moduli o sezioni di codice che sono stati implementati con cattive pratiche o utilizzando librerie obsolete. Anche se potrebbe essere allettante cancellare (o distruggere) questo codice, potrebbe non essere l'idea migliore per diversi motivi:

• Il codice legacy non è necessariamente cattivo, a volte è un buon codice che è stato scritto quando altre metodologie e tecnologie erano considerate la strada da percorrere. Tuttavia, solo perché è vecchio non significa che non funzioni.

• Potresti perdere tempo a correggere il codice che ancora funziona invece di concentrarti sulla correzione di altre parti più critiche del codice.

• A meno che tu non sia veramente sicuro di quello che stai facendo, sostituire una sezione di codice che funziona significa che stai rischiando di introdurre nuovi errori o bug.

Questo non significa che la frase “Se non è rotto, non aggiustarlo” sia una buona strategia, ma che ogni progetto ha priorità, obiettivi e vincoli di tempo. Quindi, se trovi codice che potrebbe essere migliorato, discutilo con il resto del team o con il project manager per capire quando ottimizzarlo.

Capo VIII, paragrafo 3

Ci sono strade che non devono essere seguite, eserciti che non devono essere attaccati, città che non devono essere assediate, posizioni che non devono essere contestate, comandi del sovrano a cui non devono essere obbediti.

Anche se non lo dice direttamente, potremmo interpretare questo principio come un avvertimento per evitare anti-pattern.

Sebbene l'uso di un anti-pattern possa risolvere un problema a breve termine, dovresti ricordare che a lungo termine sarà controproducente. Quindi, non importa quanto tempo risparmi, quanti bug risolvi o quanto sia conveniente per te, evitali.

Tuttavia, ci sono volte in cui potresti essere tentato di usare un anti-modello per risolvere un compito urgente, promettendo a te stesso che implementerai una soluzione adeguata quando avrai più tempo, ma ricorda una delle leggi di Murphy: tutte le soluzioni rapide diventano modifiche permanenti.

Conclusione

Sebbene lo sviluppo di software sia diverso dal comandare soldati in guerra o guidare un paese, tutto ciò deve risolvere problemi che richiedono lavoro di squadra, buona leadership, efficienza e soluzioni a lungo termine.

Tuttavia, Art of War non è l'unico libro che contiene principi che possono essere applicati allo sviluppo del software. Il principe di Niccolò Machiavelli, ne è un esempio.

In effetti, ecco un elenco di citazioni di Machiavelli che sono ancora attuali. Prova a indovinare quali sono i principi corrispondenti nel mondo dello sviluppo software.

1. Il leone non può proteggersi dalle trappole e la volpe non può difendersi dai lupi. Bisogna quindi essere una volpe per riconoscere le trappole, e un leone per spaventare i lupi.
2. Non tentare mai di vincere con la forza ciò che si può vincere con l'inganno.
3. Non è mai stato raggiunto nulla di grande senza pericolo.
4. Chi desidera un successo costante deve cambiare la propria condotta con i tempi.
5. Gli uomini in genere giudicano più dalle apparenze che dalla realtà. Tutti gli uomini hanno gli occhi, ma pochi hanno il dono della penetrazione.
6. Chi vuole essere obbedito deve saper comandare.
7. La saggezza consiste nel saper distinguere la natura dei guai e nello scegliere il male minore.
8. Non c'è modo di evitare la guerra; può solo essere posticipato a vantaggio del tuo nemico.
9. La natura crea pochi uomini coraggiosi; l'industria e la formazione ne fanno molti.