La supremazia del frontend…

Uno dei primi fatti di vita che si imparano programmando è che non tutte le mansioni sono equivalenti e, di conseguenza, “pagano” in modo differente.

Non mi riferisco ai linguaggi da utilizzare, agli algoritmi da sviluppare, alla difficoltà intrinseca di certi task. Mi riferisco al grado di visibilità che ogni lavoro offre rispetto a quanto viene prodotto.

Premessa: l’intento di questo post – e del suo titolo – è ovviamente provocatorio e va considerato come tale.

Frontend e backend

Prima di tutto, una breve definizione tratta da Wikipedia:

Nel campo della progettazione software il front end è la parte di un sistema software che gestisce l’interazione con l’utente o con sistemi esterni che producono dati di ingresso, il back end è la parte che elabora i dati generati dal front end.

Nei sistemi più complessi non è raro che i dati subiscano elaborazioni intermedie prima di passare al back end. La distinzione di una parte di ingresso e di una parte terminale nei sistemi software è un genere di astrazione che aiuta a mantenere le diverse parti di un sistema complesso logicamente separate e quindi più semplici.

Come ogni sviluppatore mi occupo sia di sviluppo lato frontend che di quello backend nei progetti che seguo anche se, lo ammetto, ho una naturale predisposizione per quest’ultimo.

Sommariamente potrei descrivere tutto ciò come volontà ed il piacere di far funzionare le cose (attività tipiche del backend) prima di dedicarmi al come presentarle al meglio (attività intimamente legate al frontend).

Poi ovviamente la priorità dei due aspetti è dettata dallo specifico progetto: in certi casi il frontend è tutto, in altri lo è invece il backend.

Arriviamo al fulcro del discorso: è dura ammetterlo, ma la prima legge di vita per uno sviluppatore orientato al backend è la seguente:

1. Puoi impegnarti quanto vuoi, inventarti miracoli tecnici sorprendenti, superare difficoltà e imprevisti assurdi ma, agli occhi dell’utente finale, il tuo lavoro tende a non vedersi, a passare inosservato. Tu stesso rischi di diventare invisibile ai suoi occhi, oscurato dal frontend e da chi lo produce.

La seconda regola è l’equivalente di un “cornuto e mazziato“:

2. Tanto più la parte del tuo lavoro nel backend è ben fatta, tanto meno lo si potrà scorgere nel progetto visto come insieme. Ossia tanto più sei bravo, tanto meno il tuo lavoro rischia di apparire. E tu con lui.

Esiste anche una terza regola – di fatto un corollario delle due precedenti – che risulta in qualche modo più generica/generale:

3. Se stai seguendo entrambi gli aspetti, non importa quanta fatica hai messo nel backend rispetto al frontend: il tuo operato sarà valutato primariamente e a partire dal primo.

Triste, difficile da accettare, ineluttabile.

Visibilità!

Nella cosiddetta “società dell’apparire“, la nostra, essere visibili, riconoscibili, associabili immediatamente a qualcosa è una chiave di successo importante. Molti ruoli importanti implicano automaticamente visibilità nonchè adeguati stipendi.

La differenza di ruolo e visibilità fra un dirigente ed un dipendente penso sia così evidente da non meritare una particolare menzione. Sussistono anche differenze non legate alla gerarchia ma alla visibilità dei risultati prodotti.

Come dire: posso progettare il motore dello shuttle, ma quello che la gente vedrà è l’esterno dello shuttle, non un dettaglio come lo è il motore, per quanto importante sia.

Ciò si verifica perchè quel tipo di dettaglio può essere riconosciuto, analizzato ed apprezzato solo da una persona sufficientemente preparata per poterlo fare o curiosa al punto di volerlo sapere.

Allo stesso modo, quando un utente visita un sito, vede il sito stesso, non l’architettura alle spalle (nè gli interessa sapere come è fatto, a meno che sia un nerd/geek e/o un curiosone). E se il sito è ben fatto, l’architettura risulta ben celata e nascosta.

Dico di più: molte persone si limitano all’aspetto visibile e, solo quando le cose vanno male, si fermano ed indagano i dettagli. C’è addirittura chi arriva al punto di tollerare e perfino giustificare carenze nelle funzionalità di un prodotto in virtù di una “grafica” buona o eccellente!

Quante volte vi è capitato un committente interessato più alla forma ed al colore di un generico bottone in un’interfaccia grafica che non alle azioni (e quindi alla “raison d’être”) scatenate da esso?

Quante volte da sviluppatori avete necessità di capire esattamente cosa deve fare un programma che vi è stato commissionato ed il cliente appare costantemente disinteressato all’argomento “funzionalità”, almeno fino a quando non è pienamente soddisfatto dell’aspetto grafico?

Si perfino infatti la storiella-consiglio del non mostrare troppo presto al cliente una bozza avanzata di interfaccia grafica perchè non sia tratto in inganno e pensi che il progetto sia presochè già completo oppure si concentri solo su quella. E voi dopo dobbiate correre per sistemare il resto.

Di chi è la colpa?

D’altra parte come dare torto all’utente-medio? Il cliente per definizione non è interessato ai dettagli intimi che costituiscono qualcosa e, d’altro canto, non dovrebbe mai essere costretto a curarsi di questo aspetto.

L’utente deve poter usare una cosa in modo agevole, non doverla prima analizzare e capire intimamente. Come dicono gli anglofoni: poter usare una cosa perchè “it just works“.

Per questo il punto critico è il frontend: se è usabile, accessibile, intuitivo, coerente, esteticamente piacevole per un utente-medio il prodotto parte già bene. Ed il successo di un prodotto si origina certamente da come appare, da quello che fa e da come l’utente riesce ad interagire con esso.

La “dittatura” del frontend

Credo, spero di aver chiarito che a mansioni apparentemente simili possono corrispondere in realtà livelli diversi di visibilità: il frontend domina.

Tuttavia, questo post non è ovviamente un invito ad abbandonare il backend e buttarsi in massa sul frontend. Tutt’altro!

Lo scopo è chiarire che i prodotti e l’importanza delle singole componenti non va valutata solamente dal punto di vista degli addetti ai lavori, della difficoltà intrinseca delle mansioni, ma deve tener conto anche dell’utente e del suo punto di vista. Che è quello che poi indirettamente paga gli stipendi acquistando i prodotti.

Che ne pensate?