Qual è la cosa più semplice che è necessaria?

C’è una citazione spesso attribuita ad Albert Einstein che mi piace abbastanza (e sono sicuro che la maggior parte lo fa):

Tutto dovrebbe essere reso il più semplice possibile, ma non più semplice.

C’è qualche indagine sul fatto che l’abbia detto o meno, ma il punto rimane indipendentemente da chi l’ha detto.

È facile prendere questa idea e applicarla alle cose che facciamo nella vita di tutti i giorni che non vogliamo fare, giusto?

• Non voglio pulire la mia stanza, quindi la riordinerò quel tanto che basta.
• Farò abbastanza lavoro per soddisfare i clienti, e questo è abbastanza.
• Adempirò [qualunque responsabilità] al [più basso grado possibile] e poiché Einstein [presumibilmente] l’ha detto, chi sono io per discutere.

Anche se non sono d’accordo (e la discussione per questo esula dallo scopo di questo post), considero questa idea nel contesto dello sviluppo web.

E per essere chiari, non sto parlando di web design. Non sono un designer. Non voglio parlare a nome di qualcosa di cui non faccio parte. Ma per quanto riguarda la fornitura di soluzioni per le persone che utilizzano software o, meglio, sviluppo web, sono molto più propenso e posizionato per parlarne.

A rigor di termini, mi ritrovo spesso a chiedermi se abbiamo reso lo sviluppo web più complicato (e perché lo abbiamo fatto) e se usare la cosa più semplice che serve è tutto ciò che è veramente necessario quando si costruiscono soluzioni per gli altri.

La cosa più semplice che è necessaria

Di recente ho scritto dei vari aspetti dello sviluppo front-end da solo (nel contesto di ottenere rapidamente qualcosa dalla porta) e di come ora abbiamo strumenti di costruzione rigorosamente per quell’aspetto dello stack di sviluppo web.

Quando si tratta di strumenti come questo indipendentemente dal livello dello stack su cui stiamo lavorando, mi ritrovo a chiedere:

Questa utilità è necessaria per rendere più semplice lo sviluppo della soluzione per qualcun altro in modo efficace e positivo?

Ad esempio, trovo che Composer sia qualcosa di molto utile. Mi consente di gestire facilmente librerie di terze parti, aggiornarle secondo necessità e incorporarle nei miei progetti.

Allo stesso modo, trovo utili gli strumenti che esaminano i miei commit prima di inviarli a GitHub perché mi consentono di rilevare problemi di qualità del codice che altrimenti richiederebbero più tempo durante il processo di revisione del codice.

Prendi ad esempio, però, alcuni degli strumenti di compilazione front-end come Grunt, Gulp, Yarn, Node, Mix e così via. Per essere chiari, alcuni di questi fanno lo stesso di altri mentre altri hanno uno scopo diverso.

Il punto su cui sto lavorando è questo:

A che punto gli strumenti che utilizziamo per lo sviluppo ostacolano la nostra capacità di costruire qualcosa e fornire qualcosa in modo efficace?

C’è qualcosa nel nostro campo che ci spinge a sentire il bisogno di rimanere all’avanguardia della tecnologia. Ma penso che ci sia una distinzione importante da fare: una cosa è essere consapevoli di uno strumento, ma una cosa è usarlo.

Consapevolezza

La cosa grandiosa di sapere che qualcosa è disponibile è avere la capacità di ricercarlo e determinare se è di qualche utilità per noi.

Questa non è un’idea rivoluzionaria o nuova, ma è una cosa che penso che alcuni di noi ignorino. Invece di ricercare e valutare, spesso lo saltiamo e vediamo quanto velocemente possiamo usarlo.

Mettendolo in uso

Il vantaggio di utilizzare qualcosa di nuovo è che otteniamo i benefici – o i benefici attesi – che l’utilità dovrebbe fornire.

Il pericolo in questo è che lo strumento potrebbe non essere disponibile in sei mesi, un anno o anche due anni e le tecnologie su cui mira a migliorare potrebbero cambiare mentre non tiene il passo.

Questo è il motivo per cui è importante mantenersi consapevoli di tale utilità determinando contemporaneamente se è utile o meno.

A proposito di questa cosa della semplicità

Tornando al mio punto originale, tuttavia, è questo: se la quantità di tempo necessaria per configurare, apprendere, sviluppare, implementare e utilizzare un nuovo strumento all’interno del flusso di lavoro, penso che valga la pena considerare se ne valga davvero la pena tempo nella tua pila di strumenti.

Ai clienti non importerà se stai utilizzando o meno qualsiasi strumento tu stia utilizzando. Si fidano che tu sia un buon amministratore della soluzione che ti stanno pagando per implementare e parte di quella responsabilità di essere saggio e diligente con il tuo tempo.

Se l’utilità che stai utilizzando ostacola in qualche modo tale responsabilità, potrebbe non valere la pena utilizzarla per un determinato progetto.

E alla fine questo è ciò che si riduce a me: se quello che sto usando mi sta aiutando a costruire la migliore soluzione possibile senza farlo a spese del cliente, allora probabilmente vale la pena usarlo. A tal fine, il set di strumenti più semplice è spesso tutto ciò che serve e niente di più.

In caso contrario, potrebbe valere la pena esaminare per l’uso in un progetto futuro ma non nel tempo del cliente.