KISS: il bacio che ogni progetto merita

KISS sta per Keep It Simple, Stupid. Non parliamo della band anni '70 col trucco pesante, anche se entrambi i concetti sono accomunati da un certo gusto per il rumore e una predilezione per l'eccesso. Quattro parole che la Marina Militare americana coniò negli anni '60 come principio di progettazione[1] e che il mondo tech ha adottato, celebrato, appeso ai muri degli uffici e poi sistematicamente ignorato al primo planning.
 

Il futuro è un'ottima scusa

C'è una tentazione quasi inevitabile nel costruire qualcosa: pensare a dove potrebbe arrivare prima ancora di capire se funziona adesso. Si chiama over-engineering, e suona sempre ragionevole quando la stai facendo.

"Dobbiamo farlo future-proof." "Meglio scalare subito." "E se poi ci servisse anche X?"

Il problema è che internet e il mondo si muovono a una velocità che non aspetta gli studi architetturali. Quello che sembra un problema di domani, cambia forma (o sparisce del tutto) prima ancora che tu abbia finito di progettarlo. C'è anche un principio gemello di KISS che vale la pena conoscere: YAGNI, You Ain't Gonna Need It[2]. Non ti servirà. La maggior parte delle funzionalità previste “per il futuro” non viene mai usata oppure cambia completamente prima di essere utile.

Fare una cosa sola e farla bene

KISS è una filosofia semplice: fare la cosa giusta, adesso, nel modo più diretto possibile.
 

Quando lavoriamo su funzioni complesse per i nostri clienti, soprattutto su piattaforme gia esistenti, il nostro approccio è quasi sempre lo stesso: spezziamo tutto in blocchi. Non solo perchè è più gestibile da sviluppare, ma perche ogni blocco risponde a domande chiare a cui saranno i consumatori a rispondere. Funziona? Piace? Vale la pena continuare? Spesso l'idea cambia strada facendo, e non è un fallimento, è il punto.

Un'intera funzione consegnata dopo mesi di sviluppo, costruita su assunzioni fatte a inizio progetto, può spesso essere una scommessa. Blocchi più piccoli, messi su progressivamente, affinati in base al feedback del precedente consentono un controllo capillare e un feedback continuo dai consumatori.

KISS come filosofia generale

La filosofia KISS vale per qualsiasi progetto, partendo soprattutto da quelli interni, quando costruiamo i nostri tool. Sappiamo dove vogliamo arrivare, ma non ci arriviamo mai in un colpo solo. Iteriamo un tassello alla volta: ogni versione risolve un problema nel modo più semplice possibile, ogni iterazione eredita quello che ha funzionato e scarta quello che sembrava brillante ma non lo era (quella che in genetica prende anche il nome di evoluzione, ma questa è un'altra storia).

Quello che emerge alla fine non è mai esattamente quello che avevamo immaginato all'inizio. Ed è quasi sempre migliore.

KISS è un bacio, che non tutti accettano volentieri, perchè semplice non vuol dire facile. Richiede la disciplina di resistere alla tentazione di aggiungere, di prevedere, di "fare le cose per bene" prima ancora di sapere se quello che stai costruendo vale la pena.

La cosa più "future-proof" che puoi fare è rilasciare qualcosa che funziona oggi, capire se vale la pena migliorarlo, e farlo. Tutto il resto è architettura per l'architettura. Semplice, no?

Qualsiasi progetto complicato può sempre essere destrutturato e affrontato in modo semplice, se non ci credi, portaci il tuo progetto e parliamone.