The Mythical Man-Month: old but gold?

Il 2023 è stato l’anno del consolidamento del metodo di lavoro del nostro Team Backend: nel 2022 lo abbiamo pensato, abbiamo raccolto gli strumenti e provato a osservarne i risultati. L’anno scorso abbiamo cominciato a raccoglierne i frutti:

• i test che non rallentano ma, anzi, rendono più veloce lo sviluppo;
• le segnalazioni che riguardano aspetti delle specifiche tecniche che non erano stati completamente compresi o analizzati;
• il cambiamento come costante, che è possibile seguire perché la struttura del codice è a suo modo semplice e rimane malleabile anche dopo centinaia e centinaia di funzionalità aggiunte.

E di questi risultati abbiamo parlato anche in eventi internazionali a colleghi di mezza Europa interessati a capire se questo modo di fare le cose possa essere utile anche a loro.

Formazione è anche leggere un libro: The Mythical Man-Month

La P di People nella missione di Aton significa, tra le altre cose, formazione: così, nell’ambito del progetto formativo del Team, ho voluto inserire la lettura di un libro proprio per aiutare a riflettere sul nostro metodo e sul “come” ogni giorno lavoriamo.

Volutamente non ho scelto un libro recente ma un libro che, nonostante i suoi anni, rimane una punto di riferimento sull’argomento: quel “The Mythical Man-Month” di Peter Brooks  – approfondisci qui – che:

• ha fissato alcuni termini nel discorso sulla metodologia di sviluppo del software,
• ci ha dato euristiche importanti nella gestione dei progetti (“Adding manpower to a late software project makes it later“, detta anche legge di Brooks),
• ha reso popolare una delle poche “leggi” che sembra reggere nonostante i cambiamenti nelle tecnologie e nelle generazioni di professionisti: la legge di Conway, cioè “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.“

Perché leggere un libro che è più vecchio di almeno dieci anni del più “esperto” membro del team?

Cosa può dire ai programmatori di oggi un libro così datato, in un campo come il nostro, che evolve così velocemente?

Proprio per la velocità con cui i nostri strumenti cambiano, le circostanze in cui lavoriamo mutano e le priorità si muovono, dobbiamo riflettere continuamente su come maneggiamo gli strumenti, anticipiamo le circostanze e leggiamo le priorità.

Siamo come un fabbro che picchia sull’incudine con un martello che non è lo stesso che ha alzato con il braccio pochi istanti prima, e l’oggetto che stiamo forgiando muta continuamente forma. Così, riflettere sul nostro metodo di lavoro ci deve portare a mantenerlo costantemente aggiornato, efficiente, verificando continuamente che i passi che seguiamo servano, ciascuno, a portare valore al prodotto finale e non siano invece avanzi di un “abbiamo sempre fatto così” o rituali ormai vuoti di utilità. Questo vale non solo per gli “strumenti” propriamente detti, come linguaggi e strumenti di programmazione, ma anche per le nostre riunioni, per il modo con cui comunichiamo e per gli strumenti che usiamo per farlo: vanno analizzati con occhio critico, anche mentre vi partecipiamo.

Il solo metodo che può essere efficace è quello che ci siamo *coscientemente* scelti: una ricetta che ci viene data da altri non può comprendere tutte le sfumature delle circostanze in cui lavoriamo, e un modo di fare che si trascina senza ricordare più il motivo per cui lo si applica è un (comodo) azzardo che solo per caso – e non sempre – porterà al risultato voluto.

The Mythical Man-Month: il confronto con il passato per stimolare la riflessione sul presente

In una disciplina in balia delle mode come lo sviluppo software, leggere la storia della pratica e come si è cercato di analizzare non tanto gli strumenti, quanto il modo in cui venivano utilizzati e come influenzavano le organizzazioni che li usavano, è uno stimolo a trovare sempre un momento per chiedersi il perché di quello che si sta facendo, e – di solito – rassicurarsi del fatto che sia coerente con lo scopo del team e del progetto a cui stiamo lavorando. Ogni tanto ci si accorge che un accessorio è diventato un orpello, oppure che uno strumento che inizialmente prometteva grandi benefici non li ha in realtà concretizzati: bisogna allora essere liberi di accettare l’esperienza e rimuovere quello che non serve, con lo scopo di lavorare meglio per produrre valore.

“The Mythical Man-Month” non ha lasciato nessuno indifferente: qualcuno ha colto i parallelismi con alcune delle metodologie più recenti, qualcun altro ha notato le differenze fra le strutture organizzative di cinquant’anni fa con le nostre, altri ancora, infine, lo hanno trovato complesso perché richiede una prospettiva sul proprio lavoro, che si guadagna con l’esperienza che sta ancora maturando. In ogni caso è stato affrontato con interesse e ha lasciato un segno che sarà oggetto di riflessione in futuro.

La prospettiva sul nuovo anno

Guardando quindi la prospettiva di questo 2024, partiamo con una lista di cose che sappiamo non funzionare bene e di miglioramenti da apportare al modo in cui lavoriamo. Sappiamo che questi perfezionamenti ci servono per poter portare a casa l’elenco, molto più lungo ed in continuo movimento, delle feature che dobbiamo realizzare per supportare la nuova piattaforma .one ed il lavoro degli altri team.