Fred Brooks è morto il mese scorso all'età di 91 anni. Attraverso il suo libro di gestione dello sviluppo software più venduto, The Mythical Man-Month Essays on Software Engineering, è diventato una leggenda della programmazione e della gestione.

Nel corso dei decenni, ho incontrato molti leader tecnologici, ma pochi sono stati impressionanti come Brooks. Anche se l'ho visto molte volte agli eventi, gli ho parlato solo una volta quando era presidente del dipartimento di informatica presso l'Università del North Carolina.

Alcuni leader tecnologici, come Steve Jobs, mostrano il loro genio come una nova. Altri, come Brooks, sono silenziosi, spiritosi e altrettanto brillanti a modo loro.

Anche senza il libro, Brooks sarebbe famoso nella storia dei computer per essere stato uno dei leader nello sviluppo di un sistema operativo utilizzabile su più di un'architettura di computer: OS/360.IBM.

Assembler 360 si è rivelato essere il mio primo linguaggio di programmazione. Avviso equo: la lingua in prima persona non dovrebbe essere IBM 360 Assembler.

Per quanto riguarda il 360 ​​Job Control Language (JCL), ho appreso allo stesso tempo che lo stesso Brooks lo ha definito "il peggior linguaggio di programmazione per computer mai ideato da chiunque, ovunque". Dirò solo che c'erano "motivi" per cui sono passato dai mainframe ai mini computer Unix.

Personalmente, tuttavia, Brooks ha osservato: “La decisione più importante che ho preso è stata quella di modificare la serie IBM 360 da un byte a 6 bit a un byte a 8 bit, che ha consentito l'uso di lettere minuscole. Questo cambiamento si è diffuso ovunque”.

Se è vero. Le architetture informatiche a 8 bit, 16 bit, 32 bit e 64 bit con cui siamo cresciuti sono iniziate con Brooks.

Diamine, la stessa parola "architettura" per design e chip di computer viene da lui.

Ma ciò che la maggior parte di noi ricorda è il suo libro, con le sue concise dichiarazioni di gestione. Ora, se solo li usassimo di più nei nostri uffici!

Cominciamo con la più nota di queste: Legge di Brooks: "L'aggiunta di manodopera a un progetto software in ritardo lo rende in ritardo".

Di volta in volta vedo aziende rovinare tutto.

Il più delle volte in questi giorni, questo errore si manifesta insistendo sul fatto che, oh, diciamo solo, tutti gli sviluppatori si presentano in ufficio il venerdì pomeriggio per giustificare il loro lavoro e lavorare su uno sprint. Sì, in realtà sto pensando a Elon Musk e Twitter.

Ma non è solo Musk. Se nella tua attività finisci sempre per dedicare molte ore extra alla fine di qualsiasi progetto per realizzarli, ti sbagli. Certo, a volte è necessario; ma se è diventata un'abitudine, hai un problema di gestione.

Un brooksismo correlato è che "nove donne non possono avere un bambino in un mese". Oppure, subentrando a Musk, non puoi nemmeno coinvolgere nove programmatori di sistemi di veicoli Tesla e creare una nuova funzionalità di social media in un mese. O tre mesi, o nove mesi, se è per questo.

Un'altra domanda correlata è: “Come può un grande progetto software essere in ritardo di un anno? Risposta: un giorno alla volta!" La soluzione è garantire che i singoli traguardi vengano raggiunti a ogni livello di gestione.

Brooks ha anche sostenuto l'idea di team software piccoli e strettamente gestiti che possono evitare il sovraccarico di funzionalità e prendersi il loro tempo.

Dopotutto, ha anche affermato Brooks, "un buon software, come il buon cibo, richiede tempo per essere prodotto".

Ora alcune persone direbbero che l'open source lo ha smentito. Nel manifesto open source The Cathedral and the Bazaar, Brooks ha sostenuto uno stile "cattedrale". Al contrario, gli sviluppatori open source e Linux organizzati in modo approssimativo rilasciavano aggiornamenti software presto e spesso.

Ma è davvero così?

Se dai un'occhiata più da vicino a come viene sviluppato Linux, vedrai molti sviluppatori. Ma sono gestiti da un gruppo molto più ristretto di funzionari guidati da Linus Torvalds. Le stesse aggiunte al codice consistono in molte piccole modifiche.

Cambiamenti significativi, come l'aggiunta di Rust a Linux o WireGuard VPN, richiedono anni.

Penso che vada notato che in epoca medievale i bazar si tenevano spesso sul terreno della cattedrale.

Brooks ci ha anche avvertito di stare attenti con i proiettili d'argento.

"Non c'è un singolo sviluppo, né nella tecnologia né nella tecnica di gestione, che da solo prometta un miglioramento di un ordine di grandezza in un decennio in termini di produttività, affidabilità, semplicità". In breve, se qualcuno del tuo team promette che la tua ultima idea, scoperta o invenzione "cambierà il mondo". Non credergli

Certo, ci sono sviluppi che cambiano il mondo.

Più di recente, vengono in mente il cloud computing, Docker/container e l'edge computing. Ma niente di tutto ciò è successo così velocemente come potresti pensare.

Tutti hanno impiegato anni per maturare e diventare significativi. Voglio dire, mentre il successo apparentemente improvviso di Docker potrebbe averti sorpreso, la sua tecnologia di container risale al 2000 e alle prigioni di FreeBSD.

Infine, anche DevOps, l'attuale principale tendenza di sviluppo, deve molto al lavoro di Brooks.

Credeva fermamente che tutti comunicassero su un progetto. (È la necessità di una comunicazione efficace che rende impossibile risolvere i problemi del software spendendo più ore di lavoro su di essi.)

Naturalmente, ora lo facciamo spesso in Git e con gli strumenti CI/CD, ma le comunicazioni ora, come lo erano all'inizio degli anni '60, sono ancora vitali per il successo della programmazione e dei progetti aziendali.

E avere successo è ciò che voleva Brooks.

Copyright © 2022 IDG Communications, Inc.

Condividi questo