Ho scritto le prime righe di codice da bambino, su uno ZX Spectrum, copiando i listati dalle riviste. Il primo gestionale “vero”, per un cliente vero, l’ho consegnato alla fine degli anni Novanta, in Visual Basic. Da allora sono passati quasi trent’anni, decine di linguaggi e un numero di progetti che ho smesso di contare.
Ogni inizio d’anno mi fermo a ripensare a cosa ha funzionato e cosa no. Quest’anno ho provato a metterlo per iscritto. Non sono regole universali: sono le lezioni che mi porto dietro e che, se tornassi indietro, vorrei sapere dal primo giorno.
1. Il problema del cliente non è quasi mai quello che ti racconta
Chi ti chiede un software ti descrive una soluzione: “mi serve una schermata che faccia questo”. Il lavoro vero è capire il problema che c’è dietro. Mi è capitato tante volte di scoprire, dopo un paio di domande, che la schermata richiesta non serviva e che bastava cambiare un passaggio del processo. Le domande migliori sono le più banali: perché lo fate così? Cosa succede se non lo fate? Chi ne soffre di più?
2. Il software più costoso è quello che nessuno usa
Ho visto progetti tecnicamente perfetti finire in un cassetto perché chi doveva usarli non era stato coinvolto. Le persone che inseriscono i dati ogni giorno vanno ascoltate all’inizio, non formate alla fine. Un’interfaccia meno elegante ma pensata con loro batte sempre un capolavoro calato dall’alto.
3. Partire piccoli non è una rinuncia
All’inizio della carriera volevo consegnare tutto, subito, completo. Oggi faccio il contrario: individuo la parte che dà più valore, la rilascio in poche settimane, la faccio usare e poi decido cosa costruire dopo. Si spreca meno, si sbaglia prima (quando sbagliare costa poco) e il cliente vede risultati concreti invece di aspettare mesi.
4. I dati vivono più a lungo del codice
I linguaggi cambiano, i framework passano di moda, le interfacce si rifanno. I dati restano. Un database progettato male ti perseguita per anni; uno progettato bene sopravvive a tre riscritture dell’applicazione. Oggi dedico ai dati più tempo che a qualsiasi altra cosa.
5. La manutenzione non è un dettaglio
Un software non è un mobile che consegni e te ne vai. Va aggiornato, protetto, adattato. Chi lo dimentica si ritrova dopo qualche anno con un sistema che nessuno sa più toccare. Quando faccio un preventivo, oggi parlo sempre anche di cosa succede dopo il rilascio.
6. La sicurezza si progetta, non si aggiunge
Per anni, come molti, ho considerato la sicurezza qualcosa da sistemare “dopo”. È un errore che costa caro. Accessi, permessi, backup, aggiornamenti: se li pensi all’inizio costano poco, se li aggiungi alla fine costano tantissimo, e spesso li aggiungi solo dopo un incidente.
7. Le mode passano, i fondamentali restano
Ho visto arrivare e passare tante “rivoluzioni” che dovevano cambiare tutto. Alcune l’hanno fatto davvero, molte no. Quello che è rimasto costante è il mestiere: capire il problema, progettare bene, scrivere codice che altri possano leggere, verificare che funzioni. Anche l’intelligenza artificiale, di cui oggi tutti parlano, la guardo così: uno strumento potentissimo, ma che va inserito dentro un software fatto bene.
Cosa non rifarei
- Dire sì a tutto. Le funzioni aggiunte “già che ci siamo” sono quelle che complicano di più e servono di meno.
- Stimare i tempi senza margine. Gli imprevisti non sono un’eccezione: sono parte del lavoro.
- Lavorare da solo su tutto. Un team con competenze diverse vede problemi che da soli non si vedono. È uno dei motivi per cui oggi lavoro con un gruppo di persone in X5G.
- Rimandare la documentazione. Il “me stesso” di sei mesi dopo non si ricorderà nulla.
Trent’anni sembrano tanti, ma la sensazione è sempre la stessa del primo giorno: c’è ancora molto da imparare. È anche il bello di questo mestiere.
Hai un progetto software in mente o uno che non sta andando come speravi? Scrivimi: a volte basta uno sguardo esterno per sbloccare le cose.
