Una delle bugie a cui in azienda si tende a credere è che si possa parallelizzare il lavoro dei developer.

Non siamo in grado nemmeno di rendere paralleli i task di un computer: otto processori non ne moltiplicano per otto la velocità, anzi spesso vanno come uno.

Se raddoppi il numero di CPU di un sistema, potrebbe andare più veloce, ma non andrà mai due volte più veloce.

Legge di Amdahl

L’illusione del management di raddoppiare le performance raddoppiando la forza lavoro è quindi errata ed utopistica.

Un primo rallentamento è dovuto alla necessità di informazione tra le parti, facciamo un esempio semplice:

L’azienda acme ha un Full Stack Developer: assume un Frontender per accelerare il lavoro e si aspetta un raddoppio delle performance con relativo dimezzamento dei tempi.

Purtroppo Frontender e Full Stack non vivono nello stesso cervello: il nuovo arrivato necessiterà di fare onboarding, di studiare l’architettura, di ambientarsi, di accettare alcune soluzioni e proporne altre dove le precedenti non lo soddisfano.

Nel frattempo tic tac il tempo scorre.

Il management che è partito da un assunto sbagliato inizia subito a spazientirsi.

Sono in due e sono più lenti di prima!

Già più lenti perché il nuovo mica si imbarca da solo: prende tempo dell’altro Dev.

I due iniziano ad essere in sintonia: sviluppano spesso in pairing e raggiungono le performance del primo developer:

Questi li pago per stare in call tra di loro a chiacchierare!

Chi paga, spazientito

I tempi per il momento sono gli stessi di prima, la qualità del codice è migliorata; i processi di sviluppo sono più chiari; il codice ora è documentato; ci sono i test; ma questo sulla timeline non si nota affatto.

I due si affiatano di più e raggiungono le performance di un Dev e mezzo. È la performance attesa per quella qualità, ma chi si aspettava un raddoppio è scontento.

Il management mugugna ma ha fretta: prendiamo altri due Dev!

Ricomincia il loop: onboarding, call, il team è cresciuto, i processi vanno cambiati, ci sono più strumenti per tenerne traccia, servono più incontri, più code review, serve fissare meglio gli standard.

E tic tac il tempo scorre.

Il management non ha ancora capito niente e dice: sono in quattro e vanno peggio di prima: serve un project manager.

Prendono uno che piace a loro: uno che sta dalla parte della timeline.

Questo del prodotto sa il giusto,non è dentro dall’inizio: bada solo ai tempi, mette stress su stress, scadenze su scadenze. Il codice viene rilasciato più velocemente, accumula un brutto debito tecnico.

Finalmente la timeline scorre veloce: il management è contento, il prodotto scricchiola e perde pezzi, il team è scontento.

Il secondo assunto è il primo ad andare via: dopo poco il primo si chiede perché sta lì.

È affezionato al proprio codice, ma alla fine piega il portatile, e se ne va.

Restano il nuovo PM, i due più nuovi: si assumono altri nuovi. Nessuno ha bene idea di come il programma funzioni. È legacy code dicono. Bisogna rifare tutto daccapo.

Abbiamo nove donne ora: il bambino non è ancora nato, il tempo è passato.

Bisogna dare la colpa a qualcuno.

A se stessi mai.