Questa è la seconda parte della traduzione di un articolo dal titolo: “Linus Torvalds’s Lessons on Software Development Management” (ovvero: lezioni di Linus Torvalds [il creatore di linux ndr] sulla gestione dei progetti di sviluppo software), scritto da Steven Vaughan-Nichols che potete trovare qui. La prima parte della traduzione la trovate qui.
<<
Sull’importanza degli strumenti di sviluppo
Ho chiesto a Torvalds cosa pensasse riguardo i cosiddetti strumenti di Software Configuration Management (SCM) come il suo Git version control system.
Lui ha risposto: "Non penso che questi strumenti abbiano una importanza fondamentale".
"Quello che è importante è che ci sia un buon workflow per il progetto, e gli strumenti possono sicuramente aiutare allo scopo," dice Torvalds. "Ma molti progetti non hanno necessariamente bisogno di tali strumenti. Tanti progetti non richiedono nessuno strumento semplicemente perchè non richiedono molti cambiamenti nel codice; se hai solo poche centinaia di pacth per release, puoi mantenerle nel modo che desideri, anche interamente a mano."
Linux è una storia a parte ovviamente. "Per il kernel, abbiamo migliaia di patch che ruotano attorno a ogni release, e all’incirca una release ogni tre mesi, e quindi per noi gli strumenti sono molto importanti," dice. "Ma continuo a pensare che non era per niente un errore fare semplicemente tarball e patch come accadeva durante i primi anni di sviluppo; allora si trattava di un progetto molto più piccolo, e ci sono voluti diversi anni prima che la mancanza di strumenti potesse diventare davvero un problema."
Inoltre, “Alcuni strumenti incoraggiano workflow che sono attivamente dannosi, e penso che CVS [Concurrent Versions System, un version control system], per esempio, abbia fatto sì che per molti progetti si sia generato il concetto di ‘commit cabal’ [cabala di commit: cioè un agglomerato di aggiornamenti non sempre coerenti ndr],” continua Torvalds. “Personalmente tendo a pensare che tar-balls e patch siano preferibili a questo, se non altro perchè rendono tutti gli sviluppatori ‘uguali’, e non creano il modello dove alcune persone hanno il privilegio di ‘commit’ e il resto sono cittadini di seconda classe.
A volte è meglio avere cittadini che siano tutti di seconda classe, al posto di avere alcune persone che abbiano troppa vita facile.”
Torvalds continua dicendo: “Molto più importanti degli strumenti sono le persone. Gli sviluppatori [the mainteiners ndr], e la mentalità.”
Mantenere le persone “in pista”
E oggi, come lavorano assieme queste persone? Ho chiesto a Torvalds quale sia stato il ruolo della Linux Kernel Mailing List (LKML) nel processo. Lui ha risposto: “Penso che linux sia stato “fatto” nella LKML più di quanto non succeda in questi giorni. Il rapporto segnale rumore, e anche solo il volume [di informazioni ndr], della LKML, fanno si che molti sviluppatori, semplicemente, non hanno il tempo di leggere la lista o, nel migliore dei casi leggono solo il soggetto dei post. Come risultato, in questi giorni, direi che, la maggior parte del vero sviluppo, avviene all’interno della sandbox di singoli sviluppatori, che successivamente comunicano con e-mail su scala maggiore di persona-a-persona.”
Detto questo, “Ciò non significa che la LKML non sia importante; significa che la LKML è diventata la ‘bacheca pubblica’ di tutti quei file e-mail individuali", aggiunge Torvalds.
“Quindi alla fine, ciò che succede è che ci sono forse quattro o cinque persone coinvolte in una discussione riguardante il proprio lavoro, ma la LKML manda tutto per conoscenza a tutti.
Tutto ciò trasforma quello che altrimenti sarebbe una pura discussione privata, in qualcosa dove altri posso intervenire.”
Ecco come funziona, “Molte persone normalmente non leggono la LKML, spesso la auto-archiviano, ma dopo reagiscono ad alcune parole chiave o, più spesso, a semplici parole delle persone coinvolte nella discussione.”
“Funziona come una sorta di archivio di concetti, ” continua Torvalds, “al quale le persone possono riferirsi successivamente, e un sacco di segnalazioni di bug finiscono per essere trovati ‘googlando’ per quelle parole. Se qualcuno solleva un problema, che potrebbe anche essere benissimo uno strano problema hardware, ma Google mostra che il problema è stato sollevato più volte nella LKML nel passato, questo inizia a indicare che il problema potrebbe essere oscuro, ma non del tutto isolato.”
“Quindi penso che LKML è veramente molto importante, ma no, non è il modo per tenere le persone ‘in pista’,” dice. “Tutti gli sviluppatori tendono a essere auto-motivanti, e hanno tutti delle idee sane (bè, i ‘core developer’ per definizione, ed è proprio per questo che diventano ‘core developer’, perchè hanno mostrato buon gusto e alta motivazione). Questo è rilevante semplicemente perchè la ‘parte pubblica’ delle discussioni è ancora importante, anche se in pratica è semplicemente solo il nucleo di una particolare discussione.
Le cose sono semplicemente diverse quando accadono all’ ‘aperto’, ” conclude Torvalds.
Delegare restando sani di mente
Una volta, Linux era un progetto solista. Adesso ha migliaia di committenti e collaboratori, Ho poi chiesto, “Quanto si delega oggi? Come si può delegare rimanendo ‘sani di mente’ e facendo andare avanti il lavoro?”
“Se c’è qualcosa che ho imparato è che devi imparare a ‘lasciare andare avanti’ anzichè controllare, le persone e il codice,” dice. “Se non pensi che qualcuno altro può farcela anche senza il tuo controllo, sarebbe meglio smettere immediamente di fare il mainteiner.”
Continua, “Si, io vengo spesso coinvolto in piccoli dettagli, ma non perchè non mi fido delle persone o non credo nella delega. Ma perchè questi dettagli mi vengono portati. O si tratta di un bug (che deriva quasi sempre da piccoli dettagli che sono stati trascurati) o è solo un piccolo problema nel workflow che dà fastidio (come lamentele sui nomi di sviluppatori non mostrati correttamente nelle versioni precedenti a un sub-mainteiner).”
Eppure, dice Torvalds, “Quei dettagli devono essere occasionali, non del tipo ‘guardare sopra la spalla dello sviluppatore per controllare tutto quello che fa.’ Io credo che i sub-mainteiner fanno la cosa giusta nel 99% dei casi. E poi, molto occasionalmente, finisco per lamentarmi a gran voce su qualcosa. ” Come il dire, per esempio, come il desktop open-source GNOME sia, o meglio non sia, andato avanti.
Così, il gioco è fatto. Queste sono alcune cose che fa Torvalds. E, se pensi di saper fare meglio, chiedi a te stesso: Ho io creato un sistema operativo universale che gira su molti supercomputer, borse, e siti web come Google? Se la tua risposta è no, io, rileggerei le sue risposte e penserei molto a come gestisci i tuoi progetti.
>>
fine!