Qualche giorno fa mi sono imbattuto nell’ennesimo pedone che ha attraversato una strada trafficata, infischiandosene bellamente dell’apposito sottopassaggio modello deluxe gentilmente messo a disposizione dall’amministrazione comunale.
Poco dopo, la solita comitiva di ciclisti della domenica transitava in mezzo alla strada e non sull’enorme ed immacolata pista ciclabile a lato della carreggiata.
Cosa si può imparare da queste situazioni? Riformulo:
Cosa può un programmatore imparare da queste situazioni “urbane”?
Si può sempre imparare, da qualunque cosa
Sarà che sono un informatico e ho una certa deformazione professionale – anche nell’osservare le cose -, ma le due situazioni sopra descritte risultano in qualche modo istruttive, perfino nel campo del software.
Passati i 30 secondi di furia nei confronti di quelle persone (che, sul momento, avrei definito incivili senza battere ciglio), ho provato ad analizzare il contesto, le cause e gli effetti di questa “debacle urbana“. Volevo capire cosa è andato storto.
Caso di studio #1: il sottopassaggio (e le funzionalità nuove, più complicate delle precedenti)
Da buon pignolo-paranoico, ho deciso di ispezionare quel sottopassaggio: decisamente ben fatto – almeno all’apparenza -, con due lunghe rampe senza scalini (cioè senza barriere architettoniche), prima e dopo il sottopassaggio vero e proprio.
Sfortunatamente questo piccolo gioiello ha una grave mancanza: costringe le persone, normodotate e non, ad allungare il percorso di un fattore 2.5x. Attraversare la strada, rischioso che sia, richiede una camminata di 6 metri mentre percorrere tutto il sottopassaggio ne richiede quasi 15: per sfruttarlo, bisogna percorre una stradina chiusa, laterale alla strada, protetta da barriere e muri.
Insomma il percorso è più lungo ed anche rigorosamente preimpostato: quello che è certo – almeno questo! – è che una volta lì dentro, si sbuca da uno dei due lati in modo perfettamente sicuro.
Poco importa che questo sottopassaggio sia stato costruito per evitare nuovi incidenti mortali – ennesimo caso di opera pubblica prodotta dopo una lunga serie di mesti eventi -, le persone lo ignorano sistematicamente, rischiando l’attraversamento in nome del risparmio di tempo.
Chiamatela pure pigrizia se vi pare, ma la pigrizia in questo caso nasconde un discorso geometrico, energetico, economico ed altro ancora: mettere a disposizione qualcosa di migliore non garantisce il successo, ossia che poi verrà usata davvero, soprattutto se non c’è vantaggio pratico tangibile per il beneficiario.
Nel mondo informatico, digitale, vale la stessa cosa, sia per gli utenti che per i programmatori.
 |
Così come una persona – magari una che ha problemi a deambulare – sceglierà la strada più corta, nel mondo informatico, uno sviluppatore sceglierà la soluzione più rapida per arrivare alla soluzione. |
Se questo significa continuare a usare puntatori, puntatori a funzioni, API documentate poco o non documentate affatto, funzioni standard del C intrinsecamente insicure come la strcpy, e chissà quale altra worst practice, non ha la minima importanza. Soprattutto se, per quanto insicura, è stata usata fino a quel momento e con profitto.
|
Le API non sufficientemente documentate sono fra le cause più note della “programmazione per permutazione”, che è l’esatto opposto della programmazione accorta, disciplinata ed affidabile. Da Wikipedia:
In modo del tutto similare, ribadisco quanto affermato in un precedente post: il “trial and error” non è una metodologia di sviluppo! |
Nel caso degli utenti, si potrebbe citare il meccanismo di sicurezza noto come User Account Control, inserito in Vista e poi rivisto e migliorato in 7. Da Wikipedia:
“User Account Control (UAC – Controllo Account Utente) è un modulo di protezione introdotto da Microsoft in Windows Vista, che gestisce i permessi dei singoli utenti del computer in modo da impedire l’esecuzione di software dannoso o il danneggiamento di dati o componenti del sistema. Uno dei principali difetti delle precedenti versioni dei sistemi Windows era infatti legato alla sicurezza ed al problema della esecuzione di molti processi ed applicazioni in modalità “amministratore di sistema”.
[...]
Molte critiche si sono levate circa il numero eccessivo di segnalazioni, ovvero di richieste di intervento da parte dell’utente, che rendono tale soluzione poco pratica: diversamente da altri sistemi operativi, le scelte operate non vengono memorizzate e questo implica che continuamente l’utente viene bersagliato dalle richieste di conferma, che alla fine perdono significato.”
Tradotto: alla fine gli utenti o provano a disattivare in blocco questa funzionalità oppure si limitano ad accettare pedissequamente tutte le notifiche e richieste di conferma, maledicendo il giorno in cui è stata introdotta questa feature.
Come opporsi a questo inghippo? Due sono le chiavi di successo perchè qualcosa sia davvero usata:
- sia (più) facile da usare;
- garantisca un uso e prestazioni in linea con le soluzioni rimpiazzate.
Se poi si riesce a rendere anche più sicure – e la sicurezza di norma porta un qualche overhead, che non sia però l’UAC – tanto meglio: l’utente-medio ed il programmatore-medio tendono generalmente a dare la priorità alle prime due caratteristiche ed a ignorare – se non costretti – tutto il resto. Salvo poi farsi male ed imprecare contro chi non li ha debitamente protetti.
|
Sta al programmatore l’onere di fornire al suo cliente (utente o altro programmatore che sia) qualcosa che sia usabile con profitto ed intrinsecamente sicuro. |
Se, in nome di un presunto livello di sicurezza superiore, complicate le cose, l’utente ignorerà il vostro sforzo e tirerà dritto sulla strada vecchia, nota e collaudata. Anche se, nei fatti, è più rischiosa.
Caso di studio #2: la pista ciclabile (e le funzionalità inserite di fretta, per “gola” o perchè ritenute “facili”)
Il caso della pista ciclabile è del tutto simile a quella del sottopassaggio ma con una differenza: la pista ciclabile è di norma una specie di corsia preferenziale che, per quanto sia spesso condivisa con i pedoni, di solito corre parallela alla strada vera e propria. In altre parole: non è il sottopassaggio che allunga e spesso di molto il percorso.
Ebbene, ho discusso con ed ascoltato diversi ciclisti lamentarsi delle piste ciclabili e sul perchè non le adoperano. In certi casi ho udito motivazioni francamente ridicole, sul genere:
“Sulle piste ciclabili ci sono spesso i pedoni che mi danno fastidio ed io devo mantenere un certo tempo!”
In altri casi ho dovuto ammettere un discreto fondo di verità. Ad esempio:
“Per accaparrarsi i fondi europei, hanno ricavato la pista ciclabile dal preesistente marciapiede. Il risultato è che, in 1 chilometro di ‘nuova’ pista ciclabile, ci sono tantissimi sali-scendi, buche, paletti, attraversamenti, perfino dossi! Ed è un continuo intralciare e discutere con i pedoni, non certo meno sbadati di noi ciclisti nel muoversi.”
Un’API o una feature inserita di fretta, con l’idea di sfruttare al volo un’occasione e perciò non pianificata in modo accorto, è prima di tutto un nuovo costo aggiuntivo e poi, sul medio-lungo periodo, rischia di diventare un’inutile zavorra, anche solo per il doverla supportare a lungo (chi ha detto: rotatorie inutili, mal progettate e mal realizzate?).
|
Le cose si devono fare se c’è una reale necessità e sempre con criterio, non solo per la fretta del guadagno sul breve periodo (es: “i fondi europei”). In ogni caso la priorità va alle esigenze di chi paga e che poi sfrutterà le novità introdotte. |
Il caso delle piste ciclabili, “ricavate” da strade e non “progettate“, si riflette nell’inserimento frettoloso di nuove feature che, appoggiandosi ed agganciandosi al codice preesistente, possono intralciarlo, rallentarlo o addirittura bloccarlo.
Pensate alle piste ciclabili ottenute trasformando strade a doppia corsia in sensi unici: in certi casi, per poche biciclette al giorno (o, per essere più precisi, per lucrare i finanziamenti) si è complicato il traffico di interi quartieri. Salvo poi dover correre ai ripari e dover ripristinare, almeno in parte, i vecchi percorsi.
Quanti sono i programmi avete visto e/o usate che, da una versione all’altra, hanno cominciato ad aver problemi dopo l’inserimento dell’ennesima inutile funzionalità che, probabilmente, nessuno davvero userà?
 |
Sto ancora aspettando un clone di Calc.exe cloud-oriented…  |
Medesimo discorso per le aggiunte apparentemente alla portata e quindi ritenute “facili e poco costose”: il fatto che qualcosa sia facile da implementare ed inserire non implica che lo si debba fare davvero e per forza: ogni nuova feature ha un costo in qualche modo calcolabile, più tutta una serie di costi addizionali, spesso non facilmente preventivabili (cfr. bellissimo post “How many Microsoft employees does it take to change a lightbulb?” di Eric Lippert).
|
Ogni programmatore ogni giorno si sveglia e sa che prima o poi dovrà scontrarsi con l’ennesimo cliente che, pur non avendo le conoscenze basilari per farlo, stimerà come “facile” l’aggiunta di questa o quella nuova funzionalità.
Ogni programmatore ogni giorno si sveglia e sa anche che qualcuno, interposto fra lui ed il cliente, darà comunque ragione a quest’ultimo. Non importa quello che dice il tuo cervello, la buona creanza, la logica, la televisione, … o anche la persona interposta: l’importante è che il cliente, prima di decidere, sia debitamente informato da te cosa comporterà e quanto costerà davvero aggiungere quella sua “bazzecola”. Se poi deciderà di proseguire, almeno non potrà obiettare nulla sul tuo operato, al momento di saldare il conto. |
Caso di studio #3 (bonus track): la nuova via, più sicura, ma ignota ai più
Uno degli aspetti estremamente importanti tanto della vita reale quanto di quella informatica è che non basta creare qualcosa di nuovo in sostituzione di qualcos’altro, ma bisogna anche pubblicizzarlo adeguatamente.
Tempo fa, recandomi in montagna con i miei genitori per le vacanze estive, ricordo di aver trovato e seguito sul nostro percorso abituale una deviazione opzionale, seguita da una nuova lunga galleria: era una scorciatoia vera e propria, che ci ha fatto risparmiare un bel po’ di tempo rispetto al percorso “canonico”.
Per quanto una galleria sia un single point of failure (SPOF) notevole nel caso di incidenti, quella istanza era migliore sotto tutti i punti di vista. Anche solo per il fatto di risparmiare ai conducenti – noi! – qualche chilometro di strada impervia, con tornanti e strapiombi nel mezzo del nulla e per questo non particolarmente entusiasmanti.
Inoltre, a conti fatti, quella galleria – pur con i limiti di velocità del caso – garantiva un’andatura costante, che si traduceva in un risparmio di tempo e carburante notevole rispetto alla soluzione precedente. Insomma, l’equivalente di aggiungere un nuovo “fast path” nel proprio codice.
Qui arriva il bello. Il problema, a mio modo di vedere, non è (solo) l’aver lasciato aperta anche l’altra strada, quella vecchia e terribilmente insicura, ma il non preoccuparsi di avvertire dell’esistenza di un’alternativa sicura, rapida, migliore: non uno straccio di cartello chiaro a segnalarne la presenza.
|
Creare una soluzione nuova e migliore vale zero se poi non si informano le persone della sua esistenza. Magari evidenziandola, anche se a scapito di una vecchia. |
Appurato che non si può chiudere una strada da un giorno all’altro – immancabilmente c’è sempre qualcuno che ci abita in quei posti sperduti ed usa quelle strade per tornare a casa – il passo successivo alla pubblicità sarebbe la fase di incentivo+disincentivo: incentivo ad usare la strada nuova e/o disincentivo ad usare quella vecchia.
Per esempio basterebbe risistemare i cartelli già esistenti in modo da spingere l’ignaro automobilista (ignaro del posto, ovviamente, e solamente in transito) a prendere la strada migliore: occhio non vede, cuore non duole.
Tralasciando anche gli evidenti costi di manutenzione doppi – che sicuramente gonfiano il portafogli di qualcuno -, questo atteggiamento è l’equivalente reale del limitarsi a creare l’ennesimo set di API che fa più o meno le stesse cose di quelli precedenti.
Alla fine continuare a supportare tutto diventa insostenibile e si arriva alla fatidica decisione di “deprecare” qualcosa, ossia marchiarlo come vecchio e superato. A quel punto è buona prassi aggiungere qualche controllo addizionale d’utilizzo, in modo che l’utente/programmatore sia informato non appena prova ad usarla. È un po’ come avvertire l’utente del precipizio qualche metro prima che ci finisca dentro: magari è tardi, ma non troppo tardi.
|
Basta un “warning” in un compilatore a scoraggiare un programmatore da usare qualcosa di vecchio, deprecato ed insicuro?
La mia esperienza dice di no. Troppi messaggi di warning ed il programmatore farà come qualunque utente alle prese con l’UAC di vista: se ne infischierà, magari cercando il modo di disabilitarli. Esattamente come avviene con i copri-pacchetti per le sigarette, che “risparmiano” al fumatore la visione dei giganteschi avvertimenti come il celebre “Nuoce gravemente alla salute”. Potete inventarvi sempre nuovi modi per avvertire qualcuno. Ma se risultate troppo insistenti – o l’”obiettivo” vi riterrà tali – i vostri messaggi cadranno inascoltati. Mai sottostimare l’ingegno di qualcuno che si sente “stressato” dai vostri ripetuti messaggi d’allarme. |
Arriviamo al punto cruciale: se si fa qualcosa a fin di bene – e lo si può dimostrare -, perchè mantenere la soluzione vecchia ad libitum?
Perchè non pubblicizzare il tutto in modo che l’utente – che contrariamente a quanto si dice non è del tutto scemo – si decida ad abbandonare appena può la strada vecchia per la nuova (e nonostante il celebre proverbio insegni l’opposto)?
Perchè non fornire date certe per forzare il cambiamento? Non come quelle, “ballerine”, del digitale terrestre: conosco gente che, all’ennesimo annuncio dello spostamento della data dello switch off, ha optato per attendere l’evento reale.
|
Ogni decisione, draconiana o meno che sia, va portata in porto nei tempi previsti ed annunciati. Altrimenti, dopo un po’, nessuno crede più a chi grida “Al lupo, al lupo!”… |
Lasciare più soluzioni aperte, pur deprecandone alcune, oltre a confondere l’utente, significa accettare che qualcuno possa continuare a rifiutarsi di passare al nuovo. E tanto prima o poi protesterà comunque: i seguaci del “si fa all’ultimo momento utile!” sono sempre in agguato.
Posso capire il discorso retrocompatibilità, che per certe aziende è fonte di reddito ma è anche una causa di staticità e di perduranti problemi.
Sono dell’idea che se una nuova soluzione serve ad impedire danni enormi, va introdotta subito, senza esitazioni e senza “periodi di grazia” per le soluzioni precedenti.
|
Lo smart pointer “auto_ptr” dello standard C++98/03. Lo standard nuovo, C++11, lo ha definito deprecato, sostituendolo con smart pointer migliori e (più) sicuri da usare.
Marcare come deprecata una funzionalità esistente – per quanto sia un buon esempio di “pubblicità” proveniente da una fonte autorevole – significa da un lato garantire un certo livello di (retro)compatibilità, dall’altra permettere ancora l’uso di qualcosa di insicuro e/o superato, che continuerà comunque a comparire sui libri come il non-plus-ultra e per chissà quanto tempo ancora. Se poi si rimanda ad un “futuro standard” la rimozione definitiva di quel qualcosa e fra una versione e l’altra dello standard passano 5 o perfino 10 anni… |
Deprecare qualcosa è come abbassare la velocità massima consentita su una strada invece di precipitarsi a coprirne le vistose buche. Apprezzo il fatto che qualcuno mi avverta di un pericolo concreto, ma se mi impedisse a priori di rischiare gradirei di più. Sbaglio?
Che ne pensate?
Digitale terrestre: per il peso che do’ alla TV ho atteso che lo switch-off forsse reale prima di cercarmi un decoder.
tanto un po’ di fermo TV puo’ solo migliorare la qualita’ della vita
E per dirla tutta, un pochino speravo in una botta di dignita’ dei tanti anti-berlusconiani che aveva l’ opportunita’ di mettere in ginocchio quella emerita fesseria che e’ il digitale terrestre semplicemente rinunciando per qualche settimana ad un futile svago.
Purtroppo acneh chi a parole si crede investito delle capacita’ di migliorare il mondo, poi, all’ atto pratico, si e’ arreso davanti al dramma di perdere qualche puntata dei proprio programmi preferiti.
Riguardo alle piste ciclabili devo ricordarti che servono solo al ciclista tranquillo che usa la bici per necessita’ e non certo ai ciclisti in tutina colorata che hanno ben altre esigenze.
Per quest’ultima categoria, un po’ come per i motociclisti, non esiste il concetto di multitasking e condivsione di risorse.
Per loro serve un sistema operativo dedicato dove fare come meglio credono, un po’ come fa Microsoft con i suoi aggiornamenti
Questo ovviamente , a prescindere dalla sensatezza della richiesta.
@enzo: sul digitale potrei andare avanti per ore ma diventerei insopportabilmente scorbutico e probabilmente triviale. Per cui sorvolerò.
Sulle piste ciclabili e ciclisti invece non sono altrettanto buono dal trattenermi: oggi ne ho beccato un altro, contromano, in una strada a senso unico e dotata di pista ciclabile “ricavata”, ampia e spaziosa. Grrrr…
PS: se il comune o chi per lui paga per un’opera pubblica come una pista ciclabile ed i ciclisti non la usano, non è colpa di chi ha pagato. Come minimo dovrebbe scattare a priori il “concorso di colpa” nel caso di incidente fra ciclista e veicolo. Come dire: ti faccio un regalo e non lo usi? Poi non lamentarti se, non usandolo, ti fai male perchè sei stato tu a scegliere deliberatamente in quel senso.
Ciao & grazie di essere passato! ^^
“Deprecare qualcosa è come abbassare la velocità massima consentita su una strada invece di precipitarsi a coprire le buche. Apprezzo il fatto che qualcuno mi avverta di un pericolo concreto, ma se mi impedisse a priori di rischiare gradirei di più. Sbaglio?”
Secondo me il paragone è sbagliato. Personalmente lo vedo più simile al terzo caso: la deviazione opzionale, migliore rispetto la strada usata precedentemente (in più, pubblicizzata da fonti autorevoli).
La priorità va alle esigenze dell’utilizzatore: eliminare invece che deprecare può portare a non effettuare il passaggio da una versione all’altra, perdendo così tutti gli altri benefici della nuova versione; un esempio simile erano i: “non uso firefox 4 perché questa estensione c’è solo nel 3.6″.
PS: non mi capita spesso di dirlo, e non è da molto che ti seguo, ma ti devo fare i miei complimenti… sei proprio un bravo blogger!
Chissà se non saresti anche un bravo sindaco
@Stefano: forse mi sono espresso male. Era un altro modo di vedere e di sfruttare – male – il meccanismo di “deprecazione”. In questo caso “deprecare” era riferito al fatto che non sapendo cosa fare (es: in presenza di più set di API concorrenti o una strada malmessa), la soluzione di continuare a permettere alla gente di farsi potenzialmente male non è la scelta migliore.
“Non so cosa fare? Marchio come deprecato qualcosa e via!” Poi sono affari di chi non legge i messaggi o cartelli, magari cambiati da un giorno all’altro senza un apparente motivo…
L’esempio che porti, su Firefox è giusto, ma nasconde un aspetto che sul medio-lungo termine non mi piace troppo: legare la decisione di aggiornare o meno qualcosa di, si spera, nuovo e migliore alla presenza di un’estensione di terze parti è un po’ preoccupante. E se quella estensione non fosse mai aggiornata? La comunità OpenSource è tanto meravigliosa quanto un po’ altalenante nel modo con cui porta avanti nel tempo i suoi progetti… o_O
Ciao & grazie di essere passato! ^^
PS: io sindaco? Naaa… Hai presente quanto durerebbe là fuori un informatico col pallino dell’ottimizzazione? Ogni delibera sarebbe un continuo “No, questa cosa non va bene! E’ come accettare di usare un algoritmo O(n^3) per ordinare un semplice array di interi!” ^^’