Ma cosa c’entra il pilota automatico con la programmazione?

Il pilota automatico è un modo di dire che ho sentito qualche anno fa, per la prima volta. Riguarda le nostre abitudini e la nostra psicologia. In sostanza dice (ti do una mia versione di come l’ho capita):

Se sei sotto stress oppure il tuo cervello è impegnato in alcune attività di primaria importanza, le attività secondarie verranno eseguite in maniera automatica in base a come sei abituato a fare.

Cosa vuol dire? Facciamo un esempio pratico. Poco fa, prima di mettermi a scrivere questo articolo, stavo affrontando il lungo viaggio in metropolitana come ogni mattina. Diversamente dagli altri giorni, oggi devo andare nel nuovo ufficio. Nello specifico, oggi è il secondo giorno di nuovo ufficio. Tra poco ti spiegherò perché è importante questa precisazione.

Il nuovo tragitto prevede che io debba percorrere lungo la linea verde della metropolitana di Milano fino a Porta Genova. Cioè devo salire sulla metro nel paese dove abito e scendere quando arrivo, senza cambi di treno.

Oggi però stavo leggendo un libro e, visto l’argomento per nulla banale, ero totalmente assorto nei miei pensieri da fare tutto il resto delle attività con il pilota automatico. Cioè tutta la parte cosciente del mio cervello era impegnata a cercare di capire e come applicare nella mia vita i concetti che stavo leggendo.

Cosa succede quindi?

Piccola premessa: per andare nel vecchio ufficio, dovevo cambiare treno, scendere dalla metro verde e prendere la metro gialla, una volta arrivato in zona Stazione Centrale.

E sai cosa è successo oggi?

Senza nemmeno pensarci, i miei occhi hanno letto “Centrale”, le mie orecchie hanno sentito la voce dello speaker che diceva “Centrale, fermata Centrale” e semplicemente sono sceso e mi sono incamminato verso i corridoi della metropolitana gialla, tutto senza pensare consapevolmente a quello che stavo facendo.

Risultato? Arrivato alla metro gialla mi sono accorto che stavo sbagliando strada e che sarei dovuto rimanere sulla metro verde, comodamente seduto. E come mai ci sono riuscito? Intendo, come mai sono riuscito ad accorgermi dell’errore?

Perchè ho dovuto chiudere momentaneamente il libro per salire i gradini e non andare a sbattere addosso a nessuna persona, perché al mattino la metro è davvero molto affollata. Chiudendo il libro, improvvisamente ho liberato le risorse mentali che prima erano impiegate nella comprensione del libro e nel cercare di capire come avrei potuto usare quelle informazioni, per dirmi:

“hey Fra, guarda che non devi più andare nel vecchio ufficio, hai sbagliato strada!”

Prima ho detto che siccome oggi è il secondo giorno nell’ufficio nuovo, c’era qualcosa da puntualizzare. Si perché il primo giorno, “stranamente”, non ho sbagliato ufficio. Come mai?

A parte che non stavo leggendo nessun libro, essendo eccitato dal fatto che era il primo giorno, ero tutto attento e focalizzato su questa novità. Quindi mai e poi mai mi sarebbe sfuggito il particolare che la strada era cambiata.

Come il meccanismo di questo racconto influisce nel tuo lavoro di programmatore?

Il pilota automatico influisce pesantemente. Diciamo che se sei un bravo programmatore, usare il pilota automatico è l’unico motivo per cui fai delle grandi cazzate in un progetto.

Proprio perchè sei bravo.

Fa schifo questa prospettiva, vero? Essere bravi e contemporaneamente fare un progetto male come nemmeno un pivellino lo farebbe. Questo mi porta a cercare di farti capire quali sono i motivi per cui un progetto va male. Questa mia convinzione, oltre ad averla formata personalmente su di me (cosa che da sola, “statisticamente”, non significa niente) l’ho potuta creare anche basandomi sui numerosi programmatori con cui ho lavorato in questi anni.

Dal 2010, infatti, io mi occupo solo ed esclusivamente di siti eCommerce e di cose in questo ambito specifico ne ho viste parecchie.

Quando sei un bravo programmatore, quando hai raggiunto quindi un discreto livello tecnico, allora cominci a mettere il pilota automatico. Inizi cioè a fare tutte le cose che normalmente fai, utilizzando:

  • le stesse tecniche
  • facendo le stesse identiche operazioni
  • utilizzando gli stessi schemi mentali

sito dopo sito, riga di codice dopo riga di codice, per anni.

Ora, se tu riesci a crearti delle abitudini sane, allora quando metti il pilota automatico, le tue abitudini lavoreranno bene e produrranno risultati soddisfacenti. Abitudini come:

  • codice scritto in modo elegante
  • attenzione maniacale ai dettagli
  • segui con assoluta scrupolosità le grafiche realizzate
  • sei esperto di usabilità e UX e quindi fai attenzione a questi aspetti

MA, c’è un grosso MA. La maggior parte dei programmatori, praticamente tutti, non riescono mai ad avere queste skill tutte e contemporaneamente. Ma analizziamole una per una.

1. Scrivere codice elegante

Questa è una delle skill dove i programmatori “se la raccontano” di più in assoluto. I programmatori, da sempre, se la raccontano su quanto sia importante scrivere del buon codice, quanto sia assolutamente necessario sul lungo periodo, visto che poi al sito che sviluppi devi tornare a metterci mano e se è fatto male, ci metterai molto più tempo. Le basi che getti ad inizio progetto, sono quelle su cui reggerà idealmente tutto il software sviluppato in futuro e quindi, se scritta male, avrai dei mal di pancia non indifferenti sul medio e lungo periodo.

Problema: quasi tutti tendono ad avere ben chiara la teoria di questo punto, ma non riescono ad applicarla. Perchè? Beh, per svariati motivi, come ad esempio, l’evergreen:

“in azienda non capiscono un cazzo e il mio capo vuole tutto di fretta e, di fretta, non si fa niente bene”.

Quindi in questo caso (non entro nel merito se sia vero o meno quello che dici) ci sono due strade: o impari a fare le cose in maniera elegante in poco tempo, quindi diventi bravissimo e velocissimo, oppure prendi atto che questa cosa non va bene e cerchi di cambiare il paradigma del “facciamo le cose in maniera veloce”.

Soluzione migliore (ma anche più lenta): inizi a prenderti il tempo necessario per fare le cose fatte bene.

Dal mio punto di vista, quindi prendendo l’argomento da un angolo leggermente più business che tecnico, il fatto che tu singolarmente diventi molto bravo e veloce va bene per te, ma non va bene per il progetto, ancora di meno per l’azienda.

L’esempio più banale è: se un team intero di persone, diciamo di almeno tre persone, lavora ad un progetto, allora tutti dovrebbero avere lo stesso livello di velocità ed eccellenza, facendo bene e velocemente le cose. Ma se solo tu di quei tre sei in grado di farlo, gli altri saranno troppo distanti da te. Quindi se il progetto “deve essere fatto in fretta” e l’unico che tiene il ritmo sei tu, c’è comunque più di un problema. Capisci che questa non può essere la soluzione.

La soluzione, invece, è rallentare le tempistiche “troppo veloci” e portarle ad una dimensione che meglio si presta ad un lavoro che può essere svolto da tutti con una qualità alta e codice scritto in maniera elegante. Queste sono le precauzioni minime per poter lavorare con un sistema che permette di produrre costantemente software di qualità.

Purtroppo, nella mia esperienza solo grandi realtà che lavorano con progetto enormi, hanno la possibilità -ma solo apparente- di prendersi molto tempo. Anche se in realtà si prendono tanto tempo (rispetto a che cosa? rispetto alla nostra percezione di quanto sia tanto tempo) ma il progetto stesso richiede tantissimo tempo e spesso sono in ritardo pure loro.

Ma quindi come faccio a prendermi il tempo necessario per un progetto?

È necessario lavorare a vari livelli. Qui vorrei insegnarti il livello d’intervento più vicino al programmatore e che puoi direttamente controllare. Questo livello di intervento presume tu abbia un capo che, da testa di cazzo qual è, vende i progetti senza tenere conto delle tempistiche reali che ci sono dietro.

Devi fargli capire le tempistiche per un progetto

Come si fa? Prima di tutto devi avere uno storico. Se non hai mai realizzato un progetto eCommerce non hai dati su cui basarti. Posso dirti questo: un progetto medio, esclusivamente frontend su Magento, dura da uno a due mesi, in media. Quindi se vi state prendendo una decina o quindicina di giorni per consegnare il frontend al cliente, state molto probabilmente sbagliando qualcosa.

Per far capire questa cosa al tuo capo, ti basterà fare un grafico Gantt. Lo so, se usi la metodologia Scrum, il grafico Gantt è una sorta di male da evitare, lo strumento infernale che nessuno vuole vedere e che nessuno ha mai rispettato, però in questo caso, con il tuo capo (non quindi con il cliente), può funzionare.

Puoi dividere il progetto eCommerce in macro aree. Ad esempio se stai affrontando lo sviluppo frontend del sito, puoi inserire le seguenti macro aree:

  • sviluppo header
  • sviluppo homepage
  • sviluppo footer
  • svilupo pagina prodotto
  • sviluppo pagina categoria e risultati di ricerca
  • sviluppo mini cart
  • sviluppo menu di navigazione

..e via dicendo..

Se, a questo punto, facendo semplicemente l’elenco di queste macro aree, riesci a fare delle stime abbastanza precise, falle e inseriscile nel grafico Gantt. Poi falle vedere al tuo capo.

Se il tuo capo è un tecnico, potrebbe mettere in dubbio alcune stime -di solito al ribasso- con frasi tipo “Dai ma per questo mica ci vuole così tanto tempo, invece di X giorni metti Y…”. In quel caso sta a te far valere la tua opinione e spiegargli perché invece hai ragione tu e non lui.

Se non è un tecnico MA è una persona di buon senso, semplicemente dovrebbe accogliere le tue richieste. Ovviamente questa soluzione prevede che lui si fidi di te, visto che gli stai dicendo quanti giorni durerà il progetto. Se non si fida di te, hai ben altri problemi da risolvere prima di dedicarti a questi aspetti.

Se non riesci a portare sufficienti argomentazioni per giustificare le stime che hai fatto, allora, molto semplicemente, non hai ben chiaro il lavoro da fare. Quindi non ti basta fare l’elenco delle macro aree, ma ti serve scrivere quanti più task possibili relativi alla macro area, in modo da identificare tutte le singole operazioni -anche le più stupide e piccole- per portare a termine quell’area specifica.

Facciamo un esempio, parliamo del menu di navigazione. In questo esempio sparerò delle cifre a caso, giusto per fare una simulazione.

Oggetto: Menu di navigazione
Stima: 4 giorni
Sotto task:

  • riscrivere totalmente il menu di navigazione perché quello standard di Magento non va bene, in quanto in grafica cambiano X e Y cose rispetto allo standard (stima: 2 giorni)
  • inserire nel menu un’immagine presa da un blocco statico, quindi da implementare perché non standard Magento (stima: 0,5 giorni)
  • creare un JavaScript per la funzionalità dropdown sia desktop che mobile, perché il plugin che usiamo di solito non va bene (stima: 1 giorno)
  • testing + eventuali fix (stima: 0,5 giorni)

Come vedi, se hai un metodo del genere, sarà molto più facile giustificare le stime che farai. Di conseguenza, sarà più facile per il tuo capo capire quali sono le problematiche relative al codice e capirà perché ti serve quel tempo in più.

Se il tuo capo è una persona di buon senso, arriverà anche a capire che non può vendere un progetto quando vuole lui o quando vuole il cliente, che se il cliente vuole un prodotto di qualità dovrà sottostare alle nostre condizioni, perchè siamo NOI gli esperti di sviluppo siti eCommerce, non lui.

L’unico problema che potresti incontrare e che può mettere in crisi questo approccio è che l’azienda per cui lavori ha bisogno di “fare cassa”. Se quella è la cosa principale, puoi portargli tutti i Gantt e le motivazioni che vuoi, lui continuerà lo stesso a vendere progetti a casaccio.

Questo genera un circolo vizioso molto brutto, che segue questo processo in loop:

  1. Vendo un progetto a casaccio con date che non vanno bene
  2. Creo software scadente
  3. Il cliente è scontento e non mi paga tutto quello che dovrebbe
  4. Ho ulteriori problemi di cassa
  5. ripeto il tutto

Questo sistema reggerà solo fino a che i soldi dei progetti in entrata saranno di più dei soldi che i progetti dei clienti scontenti escono dalle tasche dell’azienda. Ma prima o poi il giochino si rompe e sarà solo questione di tempo, prima che l’azienda per cui lavori imploda su se stessa, lasciando tutti a piedi (te compreso).

Quindi, se capisci di essere in una di queste aziende, ti consiglio di correre ai ripari in anticipo, trovandoti un posto di lavoro migliore. Perché se il tuo capo continua ad alimentare il ciclo su citato, prima o poi andrà a finire male. Ma tu sarai già preparato. Purtroppo, di capi che si improvvisano imprenditori e web-qualcosa ne è pieno il mondo e io non ho la soluzione alla stupidità umana, quindi su questo non posso aiutarti.

I successivi tre punti sono raggruppabili, perché riguardano argomenti simili:

  1. attenzione maniacale ai dettagli
  2. segui con assoluta scrupolosità le grafiche
  3. sei esperto di usabilità e UX e quindi fai attenzione a questi aspetti

Infatti, se parliamo di attenzione ai dettagli, parliamo principalmente di due cose a cui fare attenzione:

  1. i dettagli di user experience e usabilità
  2. i dettagli nel senso che il sito dovrebbe essere più simile possibile alle grafiche

User experience e usabilità

Su questo argomento, io ho un approccio pratico basato sull’esperienza. Per rimanere generici, visto che non stiamo affrontando lo sviluppo di un tema frontend particolare, diciamo che bisogna semplicemente seguire poche ma semplici linee guida di base:

  • il sito va testato utilizzandolo sui device nativi, se possibile, provando ad esempio a fare tap davvero con il dito su un pulsante del sito web, per capire se il pulsante è grande abbastanza da essere cliccato
  • il sito va testato avendo bene in mente l’utente target che utilizzerà il sito. Se sto vendendo plugin sulla piattaforma Magento Connect, il sito eCommerce potrà anche essere leggermente più elaborato perché l’utente medio è il programmatore o lo smanettone che usa il web in lungo e in largo e non è particolarmente intimorito da processi leggermente diversi dallo standard, mentre invece devo fare estremamente attenzione a non complicare nulla nel caso in cui l’utente sia una persona “normale” magari poco avvezza al web, quindi dovrò semplificare al massimo qualsiasi operazione
  • devo costantemente chiedermi: “questo modo di fare l’operazione XYZ ha senso oppure si può fare meglio?” basandoci anche sulle abitudini degli utenti target che utilizzano siti simili o la vecchia versione del sito che sto sviluppando

Per quanto riguarda invece l’attenzione ai dettagli, dico solo una cosa: pixel perfect. Effettivamente pixel perfect è uno strumento che nasce quando i siti non erano responsive.

L’utilizzo di questo strumento consiste semplicemente nel sovrapporre, al sito, una jpeg/png in modo da verificare che combacino le dimensioni, i colori, la grandezza dei font e via dicendo.. insomma, che il sito sia identico alla grafica.

Ovviamente questo non è possibile al 100% con l’attuale tecnologia responsive, perché i siti sono fluidi e le griglie si basano su percentuali, quindi a diversi spazi disponibili sullo schermo corrispondono minime diversità rispetto alla grafica. Poi ci sono alcune piccole differenze (e a volte nemmeno tanto piccole) tra come un font viene renderizzato su un particolare browser e su come, invece, viene renderizzato in Photoshop. E su questo, ad oggi, è difficile se non impossibile, avere uniformità su tutti i browser.

Insomma, le differenze, seppur minime, ci saranno sempre. Quello che invece non deve sfuggire, sono le imprecisioni su alcuni elementi come:

  • dimensioni dei font
  • margin e padding vari
  • colori dei font
  • dimensioni delle immagini (ricordo, infatti, che le immagini, in Magento, sono in tre dimensioni di default, ma “richiamando” l’immagine posso passare due valori, larghezza e altezza, per ridimensionare l’immagine e metterla in cache)

Oltre queste accortezze, che sono davvero molto importanti ma alle quali non si fa mai abbastanza attenzione, esistono altre tecniche da utilizzare e da tenere in considerazione per ottimizzare il sito e queste rientrano nell’attenzione al dettaglio, alla qualità e all’eccellenza.

Ad esempio, non mi stancherò mai di dirlo, quando si parte con un nuovo progetto Magento, bisogna fare una serie di operazioni per ottimizzare il carico di risorse che in un Magento default vengono incluse:

  • tutti quei JavaScript inutili che Magento include (come drag-n-drop, slider, ecc..) che sono fatti con PrototypeJS ma che, nella realtà dei fatti, nessun team di sviluppo utilizza più perchè, giustamente, viene utilizzata la libreria jQuery
  • tutti quei file CSS che sono relativi alle librerie PrototypeJS e che non servono più una volta che le librerie JS corrispondenti vengono eliminate
  • bisogna inoltre inserire file CSS e JavaScript solo dove effettivamente serve. Se sto includendo, ad esempio, un file JavaScript che include la funzionalità menu, ovviamente è giusto metterlo in tutte le pagine, perché il menu è sempre presente. Ma se uno script è presente in una sola pagina, come ad esempio il JavaScript che gestisce lo zoom delle foto dei prodotti, non ha alcun senso inserirlo sempre. Quindi in homepage, categoria, risultati di ricerca, carrello, checkout, dove questo plugin non serve, perché includerlo? Ovviamente va tolto.

Questi discorsi sono da prendere seriamente in considerazione, andando oltre le due reazioni tipiche di chi leggerà questo articolo. Le due reazioni sono:

  1. “Ma questo è ovvio”. No, non è ovvio proprio per niente, visto che nessuno lo fa.
  2. “Troppo difficile”. Anche qui, applicando i metodi che ho descritto, riuscirai a prendere più tempo per il progetto e poter fare le cose con il tempo che davvero è necessario.

Un piccolo appunto, che però ti salverà dalle ire del capo azienda

Tutti questi discorsi sull’eleganza del codice e dei tempi sono bellissimi e sacrosanti. Ti invito però a valutare di volta in volta le reali necessità per il progetto che stai affrontando.

Non è sempre vero che un progetto deve essere scritto a regola d’arte, con il codice elegante e in tempi più o meno lunghi. Questo è quello che piace ai programmatori, che vedono le cose dal LORO punto di vista.

In realtà esiste un altro punto di vista, quello dell’imprenditore: le cose devono essere fatte velocemente perché il tempo è tutto, nel business.

Nessuno dei due approcci è sbagliato per definizione. Diciamo che la maggior parte delle volte può essere sbagliato, quando l’imprenditore vuole fare le cose velocemente solo perché è il cliente a dettare le regole.

Ma ci sono volte in cui è giusto fare le cose un po’ male, sacrificando un po’ di qualità per procedere velocemente.

Quindi, il discorso è che di volta in volta, dovrai fare un’analisi e valutare quale dei due approcci paga di più.

Qualità o velocità?

A te la scelta, l’importante è che sia una scelta ragionata e non un vincolo messo li da qualcuno che non ha ne analizzato la situazione, ne ha le competenze per decidere.