Durante il lockdown TangoDev ha compiuto 4 anni! Dal 2016 ad oggi abbiamo lavorato su tanti, tantissimi progetti. Al termine di ogni progetto si tirano le somme, ci si guarda indietro per capire cosa ha funzionato e cosa invece si può migliorare.
Mi sono accorto che spesso al termine di ogni progetto mi ponevo sempre le stesse domande, da quelle più tecniche a quelle più inerenti alla gestione del nostro lavoro. Assetato di risposte quindi mi sono buttato su Amazon e (grazie ai suggerimenti della community di Goodreads) ho acquistato quelli che sono considerati ad oggi i libri di riferimento del nostro lavoro:
The Mythical Man Month
Code Complete 2
The Pragmatic Programmer
A contorno ho letto anche:
97 Things Every Programmer Should Know
Release It!: Design and Deploy Production-Ready Software
Il mio viaggio fra le pagine di questi libri è iniziato a gennaio di quest’anno e, pochi giorni fa, ho finalmente letto l’ultimo paragrafo (no, non sono lento, è che Code Complete da solo sono 900 pagine!).
Oggi voglio proporvi qualche riflessione sul nostro lavoro. Molte di queste riflessioni in realtà non sono frutto della lettura di questi libri, ma erano pensieri che già mi appartenevano. Nei libri ho trovato però la riprova (supportata da casi reali) e la conferma che le mie ipotesi non erano completamente sbagliate. Cominciamo!
1 – No, fare lo sviluppatore non è un lavoro facile
La prima cosa che colpisce dei libri che vi ho elencato è che sono vecchi. Come può un libro come The Mythical Man Month, la cui prima versione risale al 1975, essere rilevante ancora oggi? La risposta è che, è vero, la tecnologia in questi decenni ha fatto passi incredibili, abbiamo a nostra disposizione linguaggi di programmazione di altissimo livello e capacità di calcolo quasi infinita, ma nessuno potrà mai toglierci l’incredibile complessità della parte creativa (e organizzativa) del nostro lavoro.
2 – Sì, risparmiare sull’analisi è il modo perfetto per andare fuori budget e mancare le scadenze
Non vi sembra di sentirlo? Il vostro project manager che vi ride in faccia mentre gli state chiedendo 2 giorni per realizzare una analisi funzionale e tecnica decenti. I numeri, ahimè per il vostro project manager, dicono che è meglio se cambia lavoro.
La verità è che, dato un problema, sia esso funzionale che tecnico, il costo per la sua risoluzione aumenta esponenzialmente al progredire dello stato di avanzamento del progetto al momento della sua scoperta. In altre parole: se il problema viene individuato e risolto nelle fasi iniziali del progetto, risolverlo costa poco, se viene individuato il giorno prima del rilascio, beh…
E’ fondamentale quindi dedicare tutto il tempo necessario alla fase di analisi. Ma quando un analisi è abbastanza dettagliata? Quando renderla ancora più dettagliata significherebbe scrivere il codice.
Vi potrà sembrare una esagerazione, ma in uno degli ultimi progetti che abbiamo realizzato abbiamo provato questo approccio. Il risultato ci ha sorpreso, perchè avendo condiviso tutte le decisioni importanti nell’analisi iniziale, lo sviluppo è stato poi molto spedito e fluido, senza rollback o momenti di stop in cui ripensare il tutto. Provateci!
3 – Sì, i test automatici aiutano, ma da soli non bastano
Diciamoci la verità: molto spesso guardiamo ai test automatici come alla panacea di tutti i mali. Ma è vero? I numeri dicono che i test automatici, da soli, mediamente sono in grado di individuare al massimo il 40% degli errori.
40%? Ma è poco!
L’unico modo per raggiungere delle percentuali di copertura significative è affiancarli a qualche altro strumento, come ad esempio il pair programming o altre forme di code review più o meno formale. In questo modo le percentuali possono salire anche oltre al 90%!
Se ci pensate è incredibile: l’unico modo per avere del codice (quasi) senza errori in produzione è sempre quello di farlo vedere a qualcun’altro! (e condire il tutto con abbondanti test automatici).
Questo è uno dei motivi per cui sono convinto che il codice che realizziamo in TangoDev sia di qualità: non lavoriamo come due sviluppatori isolati, ma siamo perennemente impegnati in una code review incrociata, e questo ci permette di raggiungere livelli qualitativi non raggiungibili singolarmente.
4 – No, non lasciare finestre rotte
Wikipedia ha una bella spiegazione sulla teoria delle finestre rotte:
https://it.wikipedia.org/wiki/Teoria_delle_finestre_rotte
In soldoni il concetto è che l’unico modo per avere una codebase di qualità è non lasciare mai delle “finestre rotte”, ovvero del codice “brutto” o dei workaround imbarazzanti. Lasciare finestre rotte genera un effetto valanga, per cui lo sviluppatore dopo di voi, vedendo il vostro codice “brutto”, si sentirà autorizzato a scrivere del codice “brutto” a sua volta.
Dobbiamo essere come le giovani marmotte, e cercare di lasciare le cose un po’ più in ordine di come le abbiamo trovate, non peggio. Non lasciamo codice imbarazzante in giro dicendo “questo lo sistemo la prossima volta, lo giuro”, perchè non lo sistemeremo mai!
5 – Sì, sono capaci tutti di scrivere codice che il compilatore capisce
Scriverlo in modo che altri sviluppatori lo possano capire è meno semplice però. Da sviluppatori passiamo buona parte del nostro tempo a leggere codice preesistente cercando di capire (o meglio, indovinare) cosa faccia. Ricollegandoci quindi al punto precedente, cerchiamo di fare la nostra parte e scriviamo del codice con la stessa qualità che ci piacerebbe trovare quando leggiamo il codice degli altri. Certo, scrivere codice in questo modo è più impegnativo, ma credo sia come andare in bicicletta: una volta che ci si prende la mano poi non si può regredire, nemmeno a volerlo!
6 – No, adeguare i tempi di sviluppo di una stima per compiacere il tuo PM non fa di te uno sviluppatore migliore
“Quanto tempo ti serve per questa funzionalità?”
“10 giorni”
“Troppo, ne abbiamo bisogno tra 5 giorni! E’ URGENTE”
…se ci lavoro qualche sera dopo cena e al sabato ce la posso fare… ”Va bene, tra 5 giorni sarà pronto”.
Ci siamo cascati tutti: vogliamo andare incontro alle esigenze della azienda per cui lavoriamo, fare bella figura (pensiamo noi) e dimostrare che siamo all’altezza (e poi ha detto che è URGENTE, lo sarà davvero!).
La verità è che il messaggio che stiamo dando in realtà è che non siamo assolutamente convinti del nostro lavoro. Come possono 10 giorni diventare 5 a parità di funzionalità richieste? E’ evidente che i 10 giorni iniziali erano sparati a caso.
Quando facciamo una stima di questo tipo, dobbiamo avere la capacità di tenere le nostre posizioni: possiamo negoziare, togliere features, semplificarne altre, ma non dobbiamo cambiare le nostre stime a parità di funzionalità richieste solo per compiacere il nostro interlocutore. Se impariamo a tenere la nostra posizione paradossalmente guadagneremo punti, perché siamo convinti del nostro lavoro e non cambiamo idea in base alle pressioni esterne.
E comunque no, non è davvero URGENTE.
7 – Sì, senza curiosità sei già un dinosauro
Non giriamoci intorno: nel nostro lavoro se non resti al passo sei un dinosauro in meno di due anni. E’ vero, al giorno d’oggi per noi sviluppatori c’è tanto lavoro, anche per i dinosauri. Ma siete proprio convinti che fra 5 anni sarà ancora così?
Dal primo giorno di TangoDev restare al passo per noi è significato anche incrementare i guadagni, in quanto i nuovi strumenti e le nuove tecnologie che abbiamo scoperto ci hanno permesso di incrementare sia la qualità che la produttività.
Pensiamo ad esempio a Flutter, che ormai per noi è lo standard de facto per lo sviluppo di app. Certo, all’inizio abbiamo dovuto studiarlo e imparare il Dart, ma ora abbiamo trovato uno strumento che ci permette di realizzare app di qualità assolutamente paragonabile alle app native (se non superiore), facendoci dimenticare tutti i problemi degli altri framework ibridi (RIP Ionic, React Native, NativeScript…).
Un altro esempio che mi salta alla mente è Docker, che in TangoDev usiamo ormai da tempo come strumento per il setup degli ambienti di test locale. Certo, all’inizio abbiamo dovuto apprendere una serie di concetti completamente nuovi, ma ora possiamo porre sotto version control i nostri ambienti di test e con due comandi abbiamo un ambiente perfettamente configurato e allineato al resto del nostro team! Questo significa meno errori, meno tempo sprecato, e in definitiva, più produttività (e, devo dirvelo? Più margine). Non avete ancora disinstallato Wamp?
8 – No, non siamo tutti uguali
Una serie di studi negli ultimi decenni hanno portato alla seguente conclusione: dato un team di sviluppatori, a parità di esperienza, è stata verificata una differenza di produttività di 1 a 10.
In altre parole? Dato un team, lo sviluppatore migliore è 10 volte più produttivo dello sviluppatore peggiore. Questo ci deve far riflettere su diversi piani:
- Il pair programming/code review può essere un modo per ridurre questo divario e permettere agli sviluppatori migliori di condividere i loro approcci con il resto del team.
- Scegliamoci bene il team dove lavorare! E’ inutile perdere tempo in un team dove non sembra esserci nessuno da cui poter imparare. C’è sicuramente un team più stimolante che ci aspetta là fuori!
- Se pensiamo di valere di più di quanto ci viene riconosciuto, non dobbiamo avere paura di chiedere di più. No, non siamo tutti uguali, ci sono sviluppatori e…sviluppatori.
Per oggi basta così…
E’ stato un viaggio lungo e ho come la sensazione di avere solo scalfito la superficie. Probabilmente questo è il primo di una serie di articoli dove proverò a mettere in ordine tutti gli spunti che ho raccolto in questi mesi. Siamo talmente impegnati nel nostro lavoro quotidiano che spesso perdiamo di vista i nostri riferimenti e le motivazioni che ci spingono a migliorarci. Vi consiglio vivamente di leggervi uno dei libri che vi ho elencato (o qualcosa di simile): il semplice fatto di aprire un libro scritto da sviluppatori per sviluppatori mi ha infuso una rinnovata voglia di diventare uno sviluppatore migliore!