Avete presente quella sensazione di euforia che provate quando trovate un nuovo tool su GitHub, con una star rating che sale come un razzo e una documentazione che promette di risolvere tutti i vostri problemi esistenziali? Ecco, dimenticatela. Quella non è innovazione, è solo un biglietto di sola andata per un incubo di debugging alle tre di notte.
Recentemente è riemerso un pensiero che, sebbene non sia una news dell’ultima ora, è più attuale che mai in un’era di hype incontrollato: l’arte di scegliere la tecnologia noiosa. Sì, avete letto bene. La vera maestria non sta nel configurare l’ultimo cluster Kubernetes super-stratificato con tre database NoSQL sperimentali, ma nel saper usare ciò che già funziona, ciò che è solido, ciò che è, appunto, noioso.
L’idea è semplice, quasi zen: ogni azienda ha un budget limitato di «token di innovazione». Immaginateli come i punti esperienza di un RPG. Se spendete il vostro unico token per implementare un sistema di service discovery che è uscito dal forno ieri, vi siete appena tolti la possibilità di innovare dove conta davvero, ovvero sul prodotto. Se volete rivoluzionare il modo in cui la gente paga online, perché dovreste sprecare energie a reinventare il protocollo SSH o a scrivere un database custom? È una follia.
Scegliere la tecnologia «noiosa» non significa scegliere quella mediocre o scadente. Non sto parlando di usare software legacy che non riceve patch dal 1998. Parlo di strumenti come Postgres, Python, PHP o Memcached. Sono tecnologie che hanno già affrontato il test del fuoco. Conoscono i loro punti di forza, ma soprattutto conosciamo i loro modi di fallire. Quando un database tradizionale va in crash, sappiamo dove guardare. Quando il nuovo database ‘disruptive’ basato su un algoritmo di cui nessuno ha mai sentito parlare decide di andare in allucinazione durante un picco di traffico, siete fritti. Avete degli «unknown unknowns», ovvero problemi che non avevate nemmeno considerato perché non sapevate che potessero esistere.
Il vero obiettivo di un ingegnere senior non è accumulare un catalogo di linguaggi diversi nel proprio CV, ma risolvere problemi di business. Il ‘bagaglio’ che portiamo con noi — monitoraggio, test, deployment, manutenzione — aumenta esponenzialmente ogni volta che introduciamo un pezzo nuovo nello stack. Se ogni sviluppatore nel team decidesse di usare il proprio framework preferito, finiremmo in un caos polyglot che richiederebbe un esercito di DevOps solo per tenere in piedi le infrastrutture.
Quindi, la prossima volta che un collega vi propone di migrare tutto su una tecnologia ‘rivoluzionaria’ solo perché l’ha vista in un webinar, provate a chiedervi: «Possiamo risolvere il problema con quello che abbiamo già?». Se la risposta è sì, restate sul sicuro. Lasciate che l’hype bruci se stesso e concentratevi sulla cosa più importante: spedire codice che funzioni e che non esploda alla prima pressione di un tasto.
Source: Choose Boring Technology (2015)