Anzi, ricomparirò in persona al Bergamo Linux User Group (BGlug) fra un paio di settimane per una presentazione sul mondo dell’embedded, visto con gli occhi di uno sviluppatore Linux.

Ovviamente siete invitati tutti: accorrete numerosi, vi aspetto!

Linux Embedded: un’esperienza da dev

Chi: incontro aperto a tutti
Luogo: sede del BGlug (annuncio e mappa)
Quando: mercoledì 30/05/2012, 21:30+
Quanto: prevista un’ora circa, più eventuale fase Q&A

“Il lavoro va rubato!”

È un’affermazione forte, tramandata da chissà quante generazioni nella mia famiglia ed il succo è tutt’altro che immorale ed illegale: il lavoro sarà anche un diritto, ma va conquistato e mantenuto, perchè irrimediabilmente ce n’è e ce ne sarà sempre poco rispetto alle nostre aspettative.

In realtà, credo, il “diritto al lavoro” si concretizza nella possibilità di lavorare, non nella singola istanza/lavoro in sè.

Considerando che questo modo di ragionare mi è stato inculcato verso la fine degli anni ’80 e gli inizi dei ’90, un periodo relativamente florido e spensierato, direi che ha avuto pure un che di profetico, visti i tempi.

Cosa significa davvero?

Sbagliare ci sta: ogni giorno facciamo scelte sulla base di molti fattori e, non essendo indovini, è normale scommettere sul cavallo perdente, anche quando ci viene spacciato per un campione.

Quello che invece non è tollerabile, a mio modo di vedere, è chi non solo non scommette per principio su di sè, ma passa il suo tempo ad invidiare e magari offendere il prossimo perchè ha ottenuto il benchè minimo successo, qualunque cosa identifichi questo termine. Non parliamo poi se qualcuno fallisce: si sprecano i

“Te l’avevo detto!”

Viceversa, ammiro profondamente chi non si accontenta quando sa di poter migliorare, di poter costruire qualcosa.

“Rubare il lavoro” non è semplicemente sottrarlo a qualcun altro, quanto rendersi importanti, indispensabili nel proprio piccolo, nonostante il mantra che recita che:

“Tutti sono utili, nessuno è indispensabile.”

Ci sono molti modi per arrivare a questa condizione, ma il primo è quello più banale e faticoso: impegno. Nessuno, salvo problemi economici irrisolvibili, si priverà mai volontariamente di un collaboratore serio e competente. Perchè i collaboratori seri e competenti non sono un peso ma un guadagno deambulante. E ce ne sono sempre troppo pochi in circolazione.

Aggiungo anche che la competenza talvolta basta a perdonare pecche vistose. Ho perso il conto delle volte che ho sentito frasi come:

“È un rompiscatole e non è facile stargli vicino, però il suo lavoro lo fa veramente bene e quindi…”

Detto questo, ci sono però due punti che mi preme sottolineare.

Il buonismo non è una virtù

Mi attirerò le ire di molti, ma buonismo e lavoro non vanno d’accordo. La frase secondo cui il lavoro è un diritto è corretta finchè non la si usa come scusa per pretendere qualcosa da qualcuno, sia esso lo Stato o l’imprenditore del caso.

Per quanto generalmente solidarizzi con chiunque si trovi in difficoltà lavorative e quindi economiche, davvero non mi riesce di provare empatia per chi pretende qualcosa a priori, ad esempio chi esige un lavoro per il semplice fatto si aver concluso una certa scuola o università. Non sopporto chi si lamenta dello Stato che non gli mette davanti un lavoro in stile manna dal cielo. Rido di chi pensa e pretende che siano le aziende a dover cercare lui/lei e non viceversa. Mi infastidisce chi è in grado di lamentarsi soltanto.

Sistema efficace per zittire i petulanti e lamentosi di turno. Chiedere loro: D’accordo, ma cosa hai fatto per migliorare la tua situazione?

Più di tutto quanto però non sopporto i “poverino” qui ed i “poverino” là, usati come un amen a chiudere tutte le lamentazioni. Col buonismo non se ne esce anche perchè, diciamocelo, alla lunga diventa stucchevole e “sa di tappo”.

Più di una volta mi sono trovato in situazioni in cui un tizio, il lamentoso di turno, riceveva sistematicamente la più becera solidarietà di plastica da chi gli stava accanto, invece che un qualche “scappellotto” verbale per farlo riflettere e, possibilmente, svegliare.

Come un re che, perfino nei momenti peggiori del suo comando, continua a ricevere gli onori dei cortigiani. Mi dicono che ciò sia una forma particolare di diplomazia, che consiste nel non infierire su una persona “che ha già tanti problemi” o, più semplicemente, nel lasciare l’incombenza a qualcuno di più intimo, rasentando il bystander effect.

Sciocchezze, dico io! Un amico o un conoscente fidato di una persona non ha bisogno di compiacerla, ma piuttosto ha il dovere morale di dire quello che gli altri non vogliono ammettere, consigliando per il meglio. Meglio se in privato, cioè faccia a faccia, ovviamente.

L’invidia non ti fa guadagnare punti

Invidia non è solamente un sentimento negativo e statico verso qualcosa o qualcuno, reo di avere “ingiustamente” qualcosa più di noi. Invidia non è solo provare rancore verso qualcun altro usando la propria situazione come metro di paragone. L’invidia purtroppo è anche dinamica, ossia si può tradurre in una serie di atteggiamenti e azioni volti non a migliorare la propria situazione quanto a rovinare quella dell’obiettivo di turno.

Ebbene, con l’invidia non si va da nessuna parte. Aldilà del rischio che ogni azione di “vendetta” fallisca miseramente e torni indietro come un boomerang, ma proprio non riesco a capire perchè molta gente invece di investire tempo e risorse nel migliorare sè stessi, ne spenda molte di più per rompere le uova nel paniere a qualcun altro.

Un po’ come quegli studenti che progettano gli stratagemmi più improbabili per copiare quando nello stesso tempo potrebbero benissimo prepararsi ed evitarsi tutti i sotterfugi. Probabilmente per loro studiare è ben più noioso che inventarsi qualche numero alla MacGyver, però il discorso rischio/ricompensa parla decisamente contro le loro astuzie. Eppure c’è molta gente in gamba che si vota a questa causa: dimostrare di essere migliori, con l’imbroglio.

Che ne pensate?

“L’opinione è un’idea che possedete voi, mentre la convinzione è un’idea che possiede voi.” (John Garland Pollard)

Quello che però differenza una semplice opinione di un individuo da quello di un altro è la sua attendibilità.

Ciarlatani astenersi

Se restringiamo il campo all’ambito professionale, l’attendibilità di un parere è un riflesso della credibilità di chi lo propone. Il peggio a cui un professionista può andare incontro è essere smentibile o, peggio, smentito da qualcuno che sia più attendibile. Il passo da “credibile” a “ciarlatano” è tremendamente breve, specie se lo si paragona alla fatica che si fa per diventare – o passare per – “autorevole”.

Mi permetto di riassumere alcuni punti banali:

1. Ogni cosa che dici può essere usata contro di te, nel momento meno opportuno;
2. A parità di tutto, i pensieri messi per iscritto sono reperti duri da smentire;
3. Più testimoni, più diffusione, più probabilità di essere smentiti: sulla Rete il “diritto all’oblio” è solo una chimera;
4. Mentire può pagare sul breve periodo, ma “coprire” qualche balla detta in passato diventa via via sempre più difficile;
5. Le persone possono anche rispettare i titoli – accademici e professionali – che porti, ma quelli delimitano anche il tuo contesto di attendibilità: se spari un’idiozia in un campo che non ti compete, non puoi nasconderti dietro ad alcun titolo;
6. Se non sai, taci!

Ripensandoci, non mi pare siano così banali. Altrimenti non si spiegherebbero gli individui propensi a formulare sentenze su tutto lo scibile umano, i cattivi consiglieri di professione, i professionisti seriali delle gaffe sulla Rete, eccetera eccetera.

La tipologia peggiore

Se c’è una tipologia di individui che non sopporto proprio sono quelli che non si accorgono di formulare pareri a caso su materie che ignorano del tutto ma con l’atteggiamento di chi la sa lunga. Temo che sotto ci sia una qualche forma di competitività estrema, che fa straparlare.

Forse questa clip, presa da The Big Bang Theory, vi apparirà artificiosa, estrema, iperbolica. Eppure ogni tanto c’è qualcuno che, ragionando per “estensione”, crede di conoscere ogni cosa nel suo campo… e anche fuori o, per essere precisi, fa di tutto perchè gli altri lo credano.

Che ne pensate?

Tuttavia, come accade spesso, l’arte messa da parte prima o poi torna utile, nei momenti e nei posti più insoliti.

Prassi rischiosa

Uno dei test più basilari – ed evidentemente ascientifici – compiuti da noi programmatori è ripetere un numero arbitrario di volte un qualunque test, estrarre uno o pochi numeri da ogni iterazione e poi calcolare la media aritmetica. L’esempio più classico riguarda il consumo di CPU o di memoria.

Come ogni programmatore, nemmeno io lesino questo tipo di rozzo sistema sperimentale, ovviamente. Tuttavia recentemente, mentre stavo raccogliendo dei dati per calcolare le medie, ho avuto un flash.

Mi è tornato in mente un eccellente post di Zed A. Shaw, segnalatomi in un commento tempo fa dall’amico Larsen (grazie!), intitolato senza troppi giri di parole “Programmers Need To Learn Statistics Or I Will Kill Them All“.

Riassumo velocemente i concetti basi:

1. Sindrome della potenza del 10

Si fissa un numero arbitrario di iterazioni di test, normalmente una potenza del 10 come il 1000, senza curarsi del fatto che quel numero potrebbe tranquillamente eccedere quello necessario ad ottenere dati attendibili oppure non bastare affatto. Insomma, non basta ripetere “tante volte” un test per potersi ritenere sicuri;

2. Solo le medie

Data una serie di misurazioni si calcola la media e… stop. Il problema è che le medie, senza altri dati a supporto, tendono “coprire” facilmente situazioni preoccupanti. O per dirla alla Shaw:

The most troubling problem with these single number “averages” is that there’s two common averages and that without some form of range or variance error they are useless.

Un esempio di dato utile è rappresentato dalla deviazione standard:

La deviazione standard o scarto tipo o scarto quadratico medio è un indice di dispersione delle misure sperimentali, vale a dire è una stima della variabilità di una popolazione di dati o di una variabile casuale. La deviazione standard è uno dei modi per esprimere la dispersione dei dati intorno ad un indice di posizione, quale può essere, ad esempio, il valore atteso o una stima del suddetto valore atteso. La deviazione standard ha pertanto la stessa unità di misura dei valori osservati (al contrario della varianza che ha come unità di misura il quadrato dell’unità di misura dei valori di riferimento). In statistica la precisione si può esprimere come deviazione standard.

Esempio canonico di impiego: la storiellina della media fra due persone in cui la prima possiede 2 polli mentre la seconda nulla e la media è 1 pollo a testa. La media “copre” una situazione sbilanciata, ma la deviazione standard – per la precisione la sample standard deviation, la cui formula differisce un poco da quella “normale” -, applicata all’esempio, rivela ben altro: 1,41. Come se non bastasse, calcolare la deviazione standard è un gioco altrettanto da ragazzi, per cui non ci sono scuse. La prossima volta che qualcuno vi spara una media “a caso”, chiedetegli anche la deviazione standard: ne sentirete delle belle.

3. Cause d’interferenza

Quando si effettuano prove e si acquisiscono misure di qualcosa, bisognerebbe isolare i sistemi per essere certi di minimizzare “disturbi” ed “interferenze” dovuti ad altri fattori (confounding variable):

In statistics, a confounding variable (also confounding factor, hidden variable, lurking variable, a confound, or confounder) is an extraneous variable in a statistical model that correlates (positively or negatively) with both the dependent variable and the independent variable.

Per dire: è inutile calcolare il consumo di una risorsa (es: CPU) di un dato programma se contemporaneamente ci sono molti altri programmi in funzione e in competizione per l’uso di essa.

4. Definizione di “utente”

Prima di misurare qualcosa, ad esempio le prestazioni di qualcosa soggetto al comportamento medio di un utente, vale la pena fermarsi un attimo e definire meglio cosa si intende per “utente medio”.

Sempre Shaw:

Before you can measure something you really need to lay down a very concrete definition of what you’re measuring. You should also try to measure the simplest thing you can and try to avoid confounding. Yet still I see software developers begging for gazillions of dollars to buy some crap tool that doesn’t even mention “standard deviation”, but throws “user” around like it’s Dr. Phil treating Robert Downey Jr. for heroin addiction.

Di certo se per modello di “utente medio” si prende chi si ha a disposizione in quel momento, ossia i programmatori stessi, allora si parte male.

5. Banda a disposizione

È inutile progettare sistemi in grado di reggere migliaia di connessioni al secondo se la banda a disposizione è in grado di sostenere il traffico di poche connessioni in contemporanea.

Face it, users are both useless for fixing their computer and as a measurement of speed.

Morale della fiaba…

La parte più divertente del post di Shaw, a parte il tono diretto e schietto, è che non tratta formulone indigeste, ma pone l’accento su concetti semplici, direi logici per non dire banali all’apparenza.

Eppure, basta guardare un qualunque benchmark online per accorgersi di come questo tipo di consiglio prezioso, in realtà, venga bellamente ignorato.

O, più probabilmente, non è abbastanza noto…

Che ne pensate?

In realtà questi non è il vero e proprio autore, quanto l’editor che ha recuperato il materiale, scritto da altri autori: si tratta cioè di una raccolta di scritt, sezionati da Spolky, relativi al mondo della programmazione.

Scheda del libro

• Titolo: “The Best Software Writing I: Selected and Introduced by Joel Spolsky“
• Editor: Joel Spolsky
• Editore: Apress
• Anno: 2005 (prima edizione americana)
• Lingua: inglese (americano)
• Genere: libro tecnico
• Categoria: raccolta di scritti inerenti il mondo ed il mercato della programmazione
• Argomenti trattati: programmazione, mercato del lavoro, …
• Pagine: 328
• Prezzo: 20.30€ su Amazon.it
• Pubblico-target: sviluppatori

Introduzione

Questo libro è una raccolta di materiale disponibile da tempo sulla Rete. Il pregio nonchè il valore aggiunto dell’opera sta proprio nella selezione effettuata dall’editor – nonchè dalle sue note introduttive e a margine a ciascuno scritto -, in modo da portare alla luce vari aspetti del variegato mondo della programmazione partendo dall’assunto spolskiano che un buon programmatore è anche un bravo scrittore:

Yeah, I know: programmers hate writing. And when, for some reason, they are somehow forced to write down something, it reads like the repair manual for a DC-3, or the result of consolidating all the “don’t do this” examples from an English style guide into one page. [...]

At my own company, we instituted a policy: we only want to hire software developers who can write, and write well. [...]

The goal of this book is to encourage better writing about software by highliting some of the best writing of the year. What looked for was simple: good writing. [...]

In linea di massima, credo di concordare con questo assunto: se sei capace di scrivere bene, ossia esternare al meglio dei concetti per forza di cosa devi anche conoscere bene quello che tratti. D’altro canto, un programmatore può anche essere un genio, ma, a meno di lavorare come un eremita, non essere capace di condividere in termini comprensibili le informazioni è un grosso limite.

Non basta saper spiegare bene le cose verbalmente: metterle per iscritto è ben più difficile – niente slang, niente scorciatoie – ed è una migliore dimostrazione di abilità.

Con questa doverosa premessa, partiamo con la recensione del libro.

Il libro e la materia

Gli autori di quest’opera compilativa sanno ovviamente il fatto loro: Cory Doctorow, Bruce Eckel, Paul Graham, Eric Lippert, solo per citare quelli più famosi.

Ognuno di loro tratta un tema diverso, un punto di vista diverso su qualcosa che ha a che fare con l’informatica lato programmazione: ognuno ha cioè qualcosa di utile da segnalare al lettore.

Il bello ed il brutto del libro sta proprio in questo: molti scritti, molti temi ma (apparentemente) slegati fra loro, senza un filo conduttore che non sia l’abilità stessa degli autori di formulare ed esprimere al meglio il loro pensiero, per altro spesso in tono umoristico.

Un aspetto curioso del “saper scrivere bene” non consiste nel saper mettere una parola dopo l’altra: un discreto numero dei vari scritti riportati, di diversa lunghezza anche se mai eccessiva, è rappresentata da disegni e perfino cartoon. Degno di nota quello che “se la prende” con il cagnolino che compare nella ricerca dei file di Windows XP, un’interfaccia definitiva “silliest” ed il mini-corso du Ruby a fumetti.

Contenuti

Devo ammettere che non ho trovato un singolo capitolo-scritto non degno di una sua presentazione.Tuttavia, non potendo dilungarmi più di tanto, dovrò accontentarmi di presentarne alcuni, quelli che, a mia volta, ho ritenuto i più meritori.

“Excel as a database” di Rory Blyth mostra, ricorrendo nuovamente ai fumetti, l’ennesima variante di un pattern ricorrente: sfruttare un programma per fargli fare l’impossibile. In questo caso l’obiettivo della lamentela è il marketing, uno degli ambienti in cui quel programma la fa da padrone:

Every feature of Excel was probably abused and abused again to avoid having to use an actual database application for storage of the data.

Of course, it’s up to you to make sense of the layout, and marketing could just give a bleepity-bleep about what a pain it is to suck weird data out of Excel and “do something with it” when little or (more often) no thought has been given to possibly making the data consistent or, dare I say, orderly.

Mi ha veramente molto colpito il pezzo di Bruce Ecklel “Strong Typing Vs Strong Testing” in cui l’autore, celebre per i vari Thinking in Java e Thinking in C++, ragiona sul fatto che, in ultima istanza, non è il tipo di typing a decretare la sicurezza di un linguaggio quanto poi il suo impiego nella produzione di programmi e, di conseguenza, il testing vero e proprio di questi ultimi.

Strong testing, not strong typing.

So this, I assert, is an aspect of why Python works. C++ tests happen at compile time (with a few minor special cases). Some Java tests happen at compile time (syntax checking), and some happen at runtime (arraybounds checking, for example). Most Python tests happen at runtime rather than at compile time, but they do happen, and that’s the important thing (not when).

And because I can get a Python program up and running in far less time than it takes you to write the equivalent C++/Java/C# program, I can start running the real tests sooner: unit tests, tests of my hypothesis, tests of alternate approaches, etc. And if a Python program has adequate unit tests, it can be as robust as a C++, Java, or C# program with adequate unit tests (although the tests in Python will be faster to write).

Interessante punto di vista, soprattutto perchè proveniente da una celebrità del mondo della programmazione da cui non ci si sarebbe aspettato una difesa del typing debole presente nei linguaggi dinamici come Python. Utile, perchè demolisce l’assunzione “accademica” secondo cui “statico è bello e meglio”.

Penso che l’articolo più insolito sia quello intitolato “Starbucks does not use two-phase commit” di Gregor Hohpe in cui l’autore analizza rapidamente il modo di servire le prenotazioni in questa famosa catena di caffetterie: si va dalla gestione asincrona delle ordinazioni, alla particolare “gestione delle eccezioni” in caso di problemi, per poi concludere il ragionamento con un raffronto con il commit a due fasi ampiamente usato in informatica (es: nei DB):

All of these strategies are different than a two-phase commit that relies on separate prepare and execute steps. In the Starbucks example, a two-phase commit would equate to waiting at the cashier with the receipt and the money on the table until the drink is finished.

Then, the drink would be added to the mix. Finally the money, receipt, and drink would change hands in one swoop. Neither the cashier nor the customer would be able to leave until the “transaction” is completed.

Using such a two-phase-commit approach would certainly kill Starbucks’ business because the number of customers they can serve within a certain time interval would decrease dramatically. This is a good reminder that although a two-phase commit can make life a lot simpler it can also hurt the free flow of messages (and therefore the scalability) because it has to maintain stateful transaction resources across the flow of multiple, asynchronous actions.

Un altro scritto che merita davvero di essere letto è quello di Eric Lippert intitolato “How many Microsoft employees does it take to change a lightbulb?“. In questo pezzo l’autore spiega come anche la piccola modifica richiesta da un utente agli sviluppatori di un prodotto in Microsoft (in questo caso una nuova funzione in VB6), per quanto possa richiedere pochi minuti di lavoro per essere completata, in realtà si traduca nel lavoro coordinato di più persone, ognuna delle quali dedita ad analizzare (ed eventualmente porre il veto per) un singolo aspetto inerente a quella modifica: fattibilità, opportunità, costi/benefici, assenza di doppioni, sicurezza dell’interfaccia, internazionalizzazione, eccetera.

That initial five minutes of dev time translates into many personweeks of work and enormous costs, all to save one person a few minutes of whipping up a one-off VB6 control that does what they want. Sorry, but that makes no business sense whatsoever. At Microsoft we try very, very hard to not release half-baked software.

L’opera include anche scritti molto interessanti sul mondo del lavoro e della gestione delle persone. Molto istruttivo, ad esempio, il pezzo di Mary Poppendieck sulla “Team Compensation” in cui l’autrice spiega come sia complicato al limite dell’impossibile premiare solamente qualcuno in un gruppo di persone che hanno ottenuto dei successi senza provocare sconvolgimenti catastrofici. Lo scopo, questo è il punto focale, è trovare un sistema di riconoscimento del merito che non provochi atteggiamenti disfunzionali come “competizione” per ottenere il premio, “percezione di non equità” da chi ne viene escluso o da chi non è convinto del metodo adottato, “percezione dell’impossibilità” nell’essere esortato a compiere qualcosa di impossibile seppur dietro la promessa di una futura gratifica, eccetera.

L’autrice elenca quindi una serie di opzioni per un “reward system” che non produca i suddetti effetti collaterali, come il rendere il sistema delle promozioni legato ai requisiti soddisfatti o meno delle persone per un dato posto o il sistema di promozioni proporzionale ai fattori economici chiave dello sviluppo dell’azienda. Si tratta decisamente di un bell’articolo, di pregevole fattura, estremamente interessante e, credo, anche molto utile.

Infine, per concludere in bellezza, non posso non segnalare la serie dei due articoli “Closing the gap” di Eric Sink in cui, fra le varie cose, l’autore cerca di spiegare l’esistenza e le finalità ultime del marketing e del reparto vendite (ai programmatori?):

Working with a Sales Guy

It is quite common for people in other job functions to have some resentment of the sales guy because of these commissions. For example, the lead architect who designed your product will be wondering why the sales guy gets a cut of every sale when she does not. Is the sales guy more valuable than the person who actually created the product?

Good sales guys understand this problem and work very hard to counteract it by “sucking up” to the developers at every opportunity. [...]

Characteristics of a Sales Guy

A sales guy needs a special set of skills. They tend to be extraverts. They are usually excellent communicators with incredible interpersonal skills.

They are self-confident, sometimes to a fault. They’re usually very goodlooking and snappy dressers. Sales guys know enough about technology to be dangerous. They know how to handle themselves well in surprising situations. They know exactly when to move toward closure and ask for the deal.

A certain amount of variation from the sales guy stereotype is acceptable, but there is one trait that is absolutely a requirement: a good sales guy is someone who is motivated only by money. One of the most dangerous personnel mistakes is to hire a sales guy who cares about anything else.

A good sales guy will do only those things for which you have provided him a financial incentive (a commission). Everything else is a waste of time, and he is essentially immune to management influence through any other means.

Note that every coin has two sides. Although I consider this mercenary nature to be an important trait for a sales guy, there is a downside that accompanies this benefit. A good sales guy has incredible listening skills that only seem to work when he is working on a deal. When listening to a prospective customer, he will catch and understand every single detail, never missing something that might help close the sale. [...]

So while the greed gene can obviously create some challenges, the pros definitely outweigh the cons. Managing a money-driven sales guy ends up being simple and largely devoid of surprises. You don’t have to spend all kinds of time figuring out what motivates your sales guy like you do with your developers. All you have to do is make sure his compensation is carefully correlated with the set of things you want him to accomplish.

Conclusioni

Pur essendo una raccolta, un’aggregazione di documenti già disponibili in Rete da tempo e non particolarmente legati fra loro, questi libro si è rivelato davvero molto interessante, illuminante per molti aspetti.

Per cui non mi resta che consigliarvelo.

Voto complessivo: 8+.

Best Fit The allocator places a process in the smallest block of unallocated memory in which it will fit. [...]

First Fit Another strategy is first fit, which simply scans the free list until a large enough hole is found. Despite the name, first-fit is generally better than best-fit because it leads to less fragmentation.

È un fatto curioso della vita che non sempre il meglio sulla carta sia anche il meglio anche nella vita reale, ossia che la strada da preferirsi teoricamente, si riveli alla fine come errata, a differenza di un’altra, originariamente scartata perchè ritenuta peggiore e talvolta perfino inammissibile.

O, per dirla alla Yogi Berra:

In teoria non c’è differenza fra la teoria e la pratica. Ma in pratica c’è.

La perfezione è un punto di vista

A tratti sono scaramantico e quando mi trovo ad avere a che fare con una soluzione (accademicamente) troppo perfetta, quasi subito comincio a chiedermi dove sia l’inganno.

Filosoficamente sarà anche vero che per ogni problema probabilmente esiste più di una soluzione valida, ma poi il criterio con cui viene scelta quella da impiegare concretamente spesso non c’entra nulla col problema originario: in sostanza, ognuno di noi tende a scegliere la soluzione che risolva sì il problema, ma che ci risulti anche più comoda da impiegare.

Qualcuno vede in questo modo di agire una semplice questione di pigrizia, qualcun altro potrebbe scomodare una qualche strategia di minimizzazione dell’energia da impiegare, qualcun altro ancora potrebbe spingersi a definirla come un’applicazione del rasoio di Occam, ma il concetto in fondo non cambia: un conto è la migliore soluzione sul foglio di carta, un’altra è la soluzione effettivamente prescelta ed utilizzata.

Il metro di giudizio sulle soluzioni cambia sulla base dei nostri pregiudizi, dei nostri bias. E di quello che ci piace di più.

In ambito tecnico e reale – e qui mi rivolgo principalmente alle persone alle prime armi, neolaureati inclusi – non esiste quasi mai la scelta accademicamente ottima. Il lavoro non è una formula con le sue precondizioni univocamente determinate, ma un insieme formule a più variabili, molte delle quali indipendenti da noi che proviamo a destreggiarci fra di esse.

Per questo mi ritrovo io stesso a partire in quarta con una certa soluzione salvo poi scoprire che qualcosa non torna. Lavoro è anche questo: smussare gli angoli a soluzioni nate nell’incertezza.

Un ricordo dal passato

Non so se gli amici Cavok e Fez ricorderanno, ma durante l’esame di Metodi per il ragionamento automatico (aka: Programmazione II) ci fu chiesto di implementare, come progetto pratico, un classificatore bayesiano, ossia un programma in grado di assegnare un documento ad una categoria sulla base del contenuto.

In pratica quello che fa un comune filtro antispam: non a caso si può dire che Bayes “spopola” in quell’ambito.

C’erano vari algoritmi disponibili per l’implementazione, ma il professore ci chiese esplicitamente di usare quello denominato naive, una versione basilare e semplificata di algoritmi bayesiani accademicamente “seri”.

A leggerne il funzionamento e a compararlo agli altri, veniva immediatamente in mente il classico personaggio dei cartoni animati di una volta che riusciva a far partire un’auto levando pezzi ritenuti “inutili” (es: spinterogeno):

Questo non serve, questo non serve, …

Diciamocelo: nessuno di noi era troppo convinto della bontà di quella soluzione. Già l’attributo naive applicato ad un algoritmo non ci faceva ben sperare:

Naivety (or naïvety, naïveté, etc.), is the of being naive—having or showing a lack of experience, understanding or sophistication – often in a context where one neglects pragmatism in favor of moral idealism.

Fortunatamente ci sbagliavamo.

Perfino Tom M. Mitchell, l’autore del libro su cui studiammo nonchè una delle opere di riferimento per la materia – Machine Learning -, pareva non capacitarsi di come qualcosa di così semplice, riduttivo e quindi scartabile, funzionasse invece a dovere rispetto a soluzioni ben più accademicamente solide:

[...] The naive Bayes algorithm was then applied using two-thirds of these 20,000 documents as training example, and performance was measured over the remaining third. Given 20 possibile newsgroups, we would expect random guessing to achieve a classification accuracy of approximately 5%. The accuracy achieved by the program was 89%.

Risi a crepapelle nel leggere questa frase: un accademico metteva nero su bianco di essersi ricreduto dopo aver messo alla prova un algoritmo apparentemente pessimo. Questa frase mi è rimasta impressa da allora nella testa e la uso come monito per me me stesso quando mi viene da scartare qualcosa a priori perchè non mi pare abbastanza seria.

Finchè una soluzione non viene “fatta girare sul banco” e non ne vengono analizzati i risultati, qualunque ragionamento teorico sul suo funzionamento o sulle sue prestazioni attese, anche quello apparentemente più logico, alla fine conta quanto la peggiore delle illazioni possibili, quanto una pura supposizione non provata. Parafrasando Knuth: Beware of bugs in the above code; I have only proved it correct, not tried it.

Al contempo quella frase è anche un monito a non dare tutto per scontato. Piuttosto – questo l’insegnamento più importante -, ogni tanto vale la pena provare a prendere l’altra strada, anche solo per cambiare un po’ l’aria e vedere cosa c’è di nuovo.

Questo discorso incredibilmente vale anche a gioco iniziato: raramente è possibile cambiare soluzione in fase implementativa, ma non è neppure impossibile come sostengono certi individui. Anzi, spesso proseguire con la soluzione sbagliata costa più che ammettere l’errore e ripartire da un’altra, magari quella che era stata scartata all’inizio perchè troppo semplice.

Dopotutto è meglio ottenere un successo dovendo ricredersi e cambiando che continuare a fallire serialmente pur di continuare sulla solita, classica e collaudata strada.

Che ne pensate?

Da Wikipedia:

In computer security, full disclosure means to disclose all the details of a security problem which are known. It is a philosophy of security management completely opposed to the idea of security through obscurity. The concept of full disclosure is controversial, but not new; it has been an issue for locksmiths since the 19th century.

Vorrei partire da questi termini ed esterne il significato, ben oltre la sfera della sicurezza.

Penso sia normale provare a mantenere il proprio orticello, salvaguardandolo da eventuali concorrenti, esterni ed anche interni. Una strategia semplice ed apparentemente efficace per difendere la propria posizione sociale e professionale è negare le informazioni o fornirle incomplete o inesatte a chi potrebbe rappresentare un ostacolo o un pericolo.

È un riflesso incondizionato in certe persone, per cui è ben difficile riuscire ad ottenere qualcosa da loro a meno di continuare a tempestarle di domande più-che-precise: se poni una certa domanda, questo tipo di interlocutore si pone immediatamente sulla difensiva, temendo il peggio per la sua conoscenza faticosamente ottenuta.

Come un “mago” che per definizione non deve mai e poi mai svelare i suoi trucchi. E magari morirebbe anche, pur di non svelarli.

Sia chiaro che mi riferisco allo scambio di conoscenza perfettamente legale ossia al know-how, non certo a informazioni riservate!

Paranoia?

Ognuno ha le sue conoscenze ed è giusto che provi a valorizzarle come meglio crede. Non sono convinto però che negare informazioni o fare resistenza ostinatamente ad oltranza rappresenti un modo efficace per farlo perchè, ad un certo punto, la corda si spezza.

Sul breve periodo mantenere un certo alone di mistero sul proprio know-how può scoraggiare eventuali concorrenti, anche limitrofi, ma a patto di utilizzare questa strategia per accelerare in avanti, ossia guadagnare tempo e nuove conoscenze tali da mantenere il vantaggio: prima che qualcuno raggiunga il nostro “livello”, noi avremo già raggiunto il prossimo. È lo stesso principio alla base dell’innovazione:

“Che ci copino pure, copieranno qualcosa di già vecchio.”

Inoltre, come ho detto in passato, ogni conoscenza, soprattutto informatica, ha una sua naturale scadenza, per cui continuare a controllare a titolo esclusivo delle nozioni ormai obsolete, sul lungo periodo non paga.

Non paga perchè le informazioni col passare del tempo perdono valore e perchè qualcuno, accortosi del diniego costante di informazioni, presto o tardi proverà a farne a meno, abbandonando il vecchio in favore di qualcosa di nuovo o cercando dei workaround.

La “security through obscurity” del proprio posto di lavoro, almeno nel settore informatico, è un modello che semplicemente non funziona o non funziona a lungo:

“Security through obscurity is a pejorative referring to a principle in security engineering, which attempts to use secrecy of design or implementation to provide security. [...] Security through obscurity has never achieved engineering acceptance as an approach to securing a system, as it contradicts the principle of “keeping it simple”. The United States National Institute of Standards and Technology (NIST) specifically recommends against it in more than one document. Quoting from one, ‘System security should not depend on the secrecy of the implementation or its components.’”

Apertura!

Imparare per proprio conto è un processo faticoso e non è facile accettare di semplificare la vita ad altri tramite trasferimenti di conoscenza a ‘mo di “pappa pronta”. Soprattutto non lo è se si è in presenza di lurker, persone che si limitano ad osservare ed assimilare informazioni, senza contribuire equamente con le proprie.

Si potrebbe a questo punto pensare ad una specie di trasferimento selettivo, ossia a persone in grado di fare altrettanto: un do ut des.

Eppure, esperienza alla mano, sono ormai certo che restringere l’accesso alle informazioni, nell’era di Internet, sia in fondo inefficace, almeno quanto lo è il provare ad offuscare il codice: per quanto si possano porre paletti al prossimo, c’è sempre un prossimo più in gamba per evitarli:

“Guai al pesce grosso che si crede il più grosso.”

A questo punto, tanto vale rilasciare le informazioni, apririne l’accesso ma in modo graduale, provando eventualmente a godere dei vantaggi del guru-che-spiega-ai-suoi-discepoli. Magari non si diventerà famosi, ma guadagnarsi la riconoscenza di qualcuno è pur sempre gratificante.

Che ne pensate?

Si arriva dunque al discorso qualità: un prodotto di qualità per definizione contiene anche un numero basso di difetti riscontrabili ed effettivamente riscontrati.

Eppure, sono convinto, non basta quel numero a definire cosa sia eccellente e cosa sia mediocre.

Sbagliare sarà umano, ma i danni vanno sistemati!

Non c’è nulla di più fastidioso di trovarsi con un problema e dover attendere Godot per una soluzione. Se poi quel problema è pure dichiarato come noto, allora inalberarsi è pure sacrosanto.

Per un mero discorso di esperienza, do per scontato che la maggior parte dei problemi dichiarati come “noti” dai produttori lo siano (stati) da parecchio tempo, talvolta senza ancora una cura, altrimenti si parlerebbe di revisione-bugfix del software. In sostanza in quei casi il termine noto equivale ad abbandonato.

Per cui, passo lapalissiano, in quel calderone che si chiama qualità del software includerei anche il tempo medio di risoluzione di un problema: da cliente o utente non mi interessa nulla sapere se un prodotto ha più o meno bug della concorrenza, mi interessa disporre di qualcosa di supportato adeguatamente, il che include anche una reazione immediata o quasi alle eventuali magagne che riscontro.

Non tutti i bug nascono uguali

Da sviluppatore ho ben chiaro che esistono vari tipi di bug. Ci sono semplici errori di programmazione (es: typo), corretti nello spazio di pochi minuti e problemi via via più seri, che possono anche intaccare pesantemente il funzionamento di molte righe di codice e quindi richiedere settimane o mesi per le relative patch.

Ho anche ben chiaro che rilasciare in fretta e furia le correzioni, senza test prolungati, può causare ulteriori problemi (“cura peggiore del male”), per cui sono pronto a tollerare un’ulteriore dilatazione dei tempi, pur di ottenere una piena risoluzione dei problemi.

Uno “storico” esempio di megapatch problematico. Da Tom’s hardware: “Windows XP Service Pack 3 finally arrived to our computers this week… And is now killing AMD machines, according to Jesper Johansson, former program manager for security policy at Microsoft. The problem relates to machines with SP3 installed rebooting and then not allowing users to get so much as Safe Mode. The problem is mainly affecting AMD users who bought their machines from HP. Johansson attributes the problem to the way that HP puts images of Windows onto its machines, using the same copy for both Intel and AMD boxes.”

Forse, nei panni del cliente di turno di fronte ad un prodotto malfunzionante, potrei semplicemente recitare la parte del

“Non mi interessa nulla di cosa non va, sistemalo subito!“

Tuttavia, da sviluppatore deformato professionalmente, mi è naturale provare a capire cosa non vada e, nel caso mi riesca, trovare un qualche workaround.

Questo perchè non sono un cliente “illetterato” – passatemi il termine – e, siccome sono il primo a non sopportare le segnalazioni di errore generico degli utenti tipo

“Non va!“

cerco sempre di agevolare chi mi deve risolvere un problema, fornendo tutte le informazioni che riesco a recuperare.

Preferisco correre il rischio e sbagliarmi nel formulare ipotesi sui problemi, che complicare la vita alle persone, senza dare informazioni utili a risolvere i problemi e limitandomi ad arrabbiarmi o ad insultarle.

Dal bug alla faccenda personale, il passo non è poi così lungo…

Trovo invece inaccettabile essere messo in coda e dover attendere mesi per semplici bugfix quando ho la certezza di essere di fronte ad un problema risolvibile in poco tempo. E allora sì che mi arrabbio.

Se un produttore si ostina a farmi perdere tempo senza sistemare i problemi di cui è responsabile e, per salvarsi, tenta in qualche modo di farmi desistere dal chiedere la correzione (es: sparando tempistiche a caso oppure eccessivamente lunghe) o di rigettare in toto le mie richieste (es: “lei è l’unico ad avere quel problema”) o di circuirmi con parolacce tecniche usate a ‘mo di clava, smetto i panni della personcina mansueta e mi infervoro.

Non mi aspetto che i problemi vengano risolti in breve, semplicemente non tollero essere preso in giro.

Un altro esempio di atteggiamento oscenamente intollerabile è costituito dai bug eterni, ossia quelli che sono conosciuti da anni, mai risolti, probabilmente deprecati non meno del software a cui si riferivano.

Un esempio tratto da uno dei forum di discussione su Java sul sito di Oracle: “You’d be surprised to know that some Java API (including Java2D & Swing) bugs & RFEs I have submitted 12 years ago have still not been fixed. I doubt it’s Oracle’s fault, as much as it was Sun’s, probably a generic lack of people and resources to allocate to fixing small bugs coupled with a bad prioritization system which does not automatically increase the weight of a low-priority bug after it has spend some times/months/years in the bug-db.”

Deontologia professionale cercasi

Settimana scorsa ho pubblicato il video “La professione dello sviluppatore” in cui l’autore, Gabriele Lana, parla del significato e del valore fondamentale dell’etica per un professionista serio, qualcosa che gli consenta di stagliarsi dalla massa della mediocrità e, possibilmente, permettergli di ottenere il giusto riconoscimento da chi è disposto ad investire su di lui.

Parla anche di assumersi le responsabilità, avendo ben chiaro che ogni bug che impedisce all’utente di sfruttare quello per cui ha pagato è tempo di vita ingiustamente sottrattogli.

Ecco, reagire ai bug non è soltanto levarsi di torno e in fretta gli utenti-rompiscatole, ma è soprattutto un buon modo per farsi valere in quanto professionisti dotati di una forte deontologia professionale agli occhi del cliente.

Non limitatevi a vendere un prodotto ad un cliente, ma pensate a comprare la sua fiducia offrendogli il miglior servizio che potete offrirgli. Fatelo ed in qualche modo sarete ricompensati

Che ne pensate?

Avevo in mente di scrivere e pubblicare un nuovo post e invece mi sono trovato a rivedere questo capolavoro (nessuna ironia nel dirlo) più e più volte, non smettendo di ridere e di pensare a quanta secolare saggezza trapeli da esso.

Finchè alla fine ho deciso, eccezione a quanto mi ero ripromesso circa i contenuti di questo blog, di ripubblicarlo/condividerlo anche io.

Non so davvero cosa aggiungere di più: tanto di cappello all’autore, Gabriele Lana.

Per semplificare, il discorso si è ridotto a cosa usare fra Windows Presentation Foundation (WPF) opportunamente adattato, Silverlight oppure ASP/ASP MVC, con un browser che magari supporta HTML 5. Questo per restare sulle tecnologie più blasonate e senza impelagarsi in altre scelte, meno note e probabilmente meno diffuse.

Si arriva dunque al problema:

“Come valutare e scegliere fra più tecnologie prima di impiegarle?”

Il mio decalogo per una scelta ponderata

Ecco dunque un insieme di punti, una sorta di decalogo degli aspetti che ritengo fondamentali in una comparazione e scelta fra più prodotti tecnologici. Ne esistono certamente altri, però questi sono quelli su cui generalmente baso le mie scelte.

Credo che la loro specifica importanza non sia costante per cui non li elenco secondo un ordine preciso e predeterminato: in certi progetti alcuni emergeranno indiscutibilmente come punti-chiave mentre in altri casi saranno relegati ad un ruolo marginale, trascurabile.

Applicherò poi ciascun punto al caso sopra menzionato, a titolo d’esempio.

1. Diffusione e promozione

Salvo mercati di nicchia, magari con pochi vendor che si contendono il mercato, penso sia estremamente rischioso puntare su qualcosa di poco noto e diffuso.

Non fraintendetemi: non è detto che la mancanza di diffusione sia da imputarsi solamente ad una qualità medio-bassa dei programmi o al fatto che un produttore – e includo anche le comunità FOSS, non solo i vendor di software proprietario – sia relativamente piccolo e poco “potente” dal punto di vista del marketing.

Mi riferisco al fatto che spesso ho come l’impressione che certi programmi siano letteralmente buttati sul mercato in fretta e furia, per poi essere abbandonati alla loro sorte. È un po’ l’atteggiamento di una certa parte del software FOSS, rilasciato “as is” e quindi senza garanzia alcuna: apprezzo l’impegno ed il “regalo” del software stesso – e del tempo e risorse impiegate per produrlo – ma regalare qualcosa di inusabile o non debitamente seguito è fare un regalo monco (cfr. ad esempio questo vecchio post).

Penso sia chiaro che esista una correlazione stretta fra “seguire“, supportare i prodotti rilasciati e la loro diffusione.

Nel caso specifico delle tecnologie Microsoft elencate, sono sostanzialmente tutte diffuse e relativamente affermate anche se, come vedremo nel prosieguo, non possono essere messe esattamente sullo stesso piano.

2. Requisiti

Ognuno ha le sue esigenze, perfino i prodotti stessi (es: dipendenze).

Scrivere software significa dover pensare a come incastonarlo all’interno di un progetto e non sempre si ha uno spettro di opzioni completo. Spesso tocca scegliere qualcosa per adattarlo ad un contesto pre-esistente, alle esigenze particolari del committente, alle conoscenze attuali di chi effettuerà materialmente il lavoro e perfino alla filosofia e alla “storia tecnologica” dell’azienda, includendo nel novero anche eventuali accordi commerciali e privilegiati con altre aziende.

Fra i requisiti rientrano anche le funzionalità minime richieste e quelle opzionali: ciò che ci serve ora e ciò che potrebbe servirci in futuro.

Paradossalmente quando si hanno pochi requisiti stringenti la situazione tende a presentarsi come più rischiosa: il fatto di aver carta bianca nelle scelte tecnologiche significa sobbarcarsi più responsabilità e quindi assumersi più rischi.

Nel caso del problema citato ad inizio post, si parla di tecnologie già diffuse ma non del tutto note alla mia conoscenza per cui questi ha deciso di prendersi un po’ di tempo, magari cercando informazioni di prima mano da chi effettivamente le ha già sperimentate. Non avere requisiti precisi e stringenti lo ha messo un po’ in difficoltà e quindi non può che agire con estrema cautela.

3. Preferenze, gusti e pigrizia

Che lo si voglia o meno, preferenze e gusti personali hanno un impatto notevole nelle decisioni, tanto da rientrare fra i requisiti, spesso opportunamente mascherati ed occultati come dati di fatto.

Normalmente le tecnologie già note e sperimentate con successo tendono a qualificarsi sempre come punti di partenza impliciti, tanto per i programmatori quanto per i clienti che in passato “si sono trovati bene con questo e quello“.

Di solito si tratta di un bene – “chi lascia la strada vecchia per la nuova…” -, ma il rischio di voler “far fare la pizza” a qualcosa che non è progettato per farla è sempre presente. Medesimo discorso per gli effetti negativi dovuti alla pigrizia o indolenza nel dover imparare qualcosa di nuovo.

Nel caso specifico, la conoscenza già utilizza ed apprezza il C#, per cui opterebbe per mantenersi su qualcosa che non gli imponga di “spostarsi” troppo dal framework .Net. Le tre tecnologie citate si appoggiano e sfruttano tutte il framework ma non solo: che si tratti di Javascript, HTML, XML, XAML o altro ancora, spostare sul web dei prodotti basati sulle Windows Forms non è esattamente un gioco da ragazzi, per cui la preferenza ricadrà in qualche modo sulla soluzione che renderà la transizione meno dolorosa in termini di tempo ed energie impiegate.

4. ROI e Know How previsti

Il “ritorno dell’investimento” o ROI, in questo caso ha duplice natura, in senso cioè esplicito ed implicito. Quello esplicito, direi tradizionale, è legato ai guadagni scaturiti dai prodotti rilasciati in relazione ai costi affrontati, mentre quello implicito è legato alle conoscenze (know how) accumulate in fase realizzativa da parte del programmatore.

Buttarsi su una tecnologia nata vecchia o non molto diffusa o non debitamente seguita e “spinta” sul mercato dal suo produttore, magari garantisce comunque un ritorno sul breve/medio periodo ma non su quello lungo: si ha già in qualche modo la certezza di dover rivedere le scelte di lì a poco tempo. Ciò può produrre un impatto negativo sull’economia aziendale e sulle strategie commerciali presenti e future.

Lo stesso discorso si applica all’esecutore materiale, ossia al programmatore: il gioco-sforzo intellettuale dell’imparare deve valere la famosa candela e, possibilmente, i frutti devono continuare nel tempo.

Altrimenti il tutto si riduce all’equivalente di una partita a guardie e ladri fra chi continua a sfornare nuove tecnologie – magari dimenticandosi in fretta di quelle precedenti e già obsolescenti – e chi poi deve impararle e sfruttarle per poco tempo, fino all’iterazione successiva del gioco.

Nel caso dell’esempio, si tratta comunque di tecnologie diffuse ed il know how ottenibile imparandole ed usandole rappresenta comunque un buon investimento per il programmatore, a patto di mantenersi aggiornati vista la rapidità di evoluzione che le contraddistingue. Usarle rappresenta cioè qualcosa di richiesto e quindi di spendibile sul mercato: ottime voci nel curricum vitae.

5. Curva di apprendimento

È notevole osservare come il ciclo di vita di molte tecnologie spesso si dimostra nella pratica assai breve se comparata al periodo medio richiesto per la loro diffusione, incluso quello di apprendimento. Cioè se serve un annetto prima che qualcosa emerga e si diffonda, nel tempo che ciò avviene, spesso sul mercato si sta già parlando o sta per essere rilasciata la versione successiva, talvolta incompatibile con la versione precedente.

Personalmente detesto chi mi impone di continuare a inseguire, nonostante gli sforzi quotidiani per mantenermi al passo con i tempi e con lo stato dell’arte.

Per capirci, il C# 3 rispetto al 2 è un altro linguaggio, fortunatamente molto migliorato, ma con uno stile di programmazione nuovo ed in qualche modo insolito per il programmatore C# “medio”: abituato alla programmazione strutturata/imperativa ed OOP, ora ha a disposizione anche feature dei linguaggi funzionali che pian pianino stanno diventando lo stile di programmazione standard e moderno. E ancora, nel mentre le persone hanno iniziato a sfruttare debitamente il 3 è già uscito il 4 e si parla già del 5.

Apprezzo molto quando un’azienda sforna prodotti a raffica interessanti – per far felici primariamente gli azionisti, credo -, ma apprezzo di meno quando non mi riesce di imparare ad applicare qualcosa di nuovo e ormai diventato basilare prima che esca la successiva.

Sfortunatamente pare che l’unico modo per mantenersi veramente aggiornati è comportarsi da early adopter seriali: appena esce sul mercato qualcosa di nuovo, pare sia necessario iniziare ad usarla fin da subito, con tutti i rischi del caso. A fronte del rischio di imparare qualcosa che diventa rapidamente inutile, questo atteggiamento ha generalmente il pregio di mantenere controllabile la curva di apprendimento: tecnologie “facili e intuitive” possono richiedere molto tempo se si lascia passare troppe versioni, mentre tecnologie relativamente complesse sono generalmente più alla portata se si cerca di tener traccia della loro evoluzione, release dopo release.

Non ho citato il C# per caso: le continue novità non hanno impatto solo sul linguaggio in sè ma anche sulle tecnologie correlate, come ASP e Silverlight stessi. Ad esempio aggiornare un progetto da una release all’altra dell’ambiente di sviluppo non sempre è una passeggiata.

Questo per dire che non basta trovare e scegliere una tecnologia per completare in fretta un porting come quello dell’esempio, c’è molto altro da considerare.

6. Passato: comportamento del vendor

Questo è un punto che sistematicamente non viene mai abbastanza debitamente affrontato ma è estremamente importante. Premesso che la storia di un’azienda, come tutto del resto, è fatta di alti e bassi, talvolta vale la pena riflettere sul comportamento commerciale/tecnologico di un vendor: continua a cambiare tecnologie, impedendoci di pianificare su un periodo medio-lungo (3-5 anni), oppure innova ma mantenendo aggiornate tecnologie anche vecchie?

Che poi, paradossalmente, “vecchio” nel mondo della tecnologia non significa un bel nulla. Altrimenti non si spiegherebbe perchè lo standard C continui a supportare comportamenti strani, scorretti e inconsistenti tipici di quando è nato – ossia nei primi anni ’70 – od il perchè del prolungato supporto a Windows XP, il cui termine ultimo è stato progressivamente posposto all’8 Aprile 2014. Questo perchè quando qualcosa viene immesso sul mercato e qualcuno lo usa, non importa se nel frattempo verrà indicato come obsoleto e deprecato, qualcuno continuerà ad usarlo all’infinito: “deprecato” è solo un suggerimento.

Il supporto al “passato” di un’azienda può impedirle di innovare “con le mani libere” ma nel contempo può garantirle ancora dei guadagni. Eppure ci sono aziende, vedi talvolta Apple, che quando lo ritengono opportuno, fanno tabula rasa del passato o predispongono un periodo di transizione limitato e non estendibile.

Nell’esempio all’inizio del post, Microsoft ha sempre garantito un supporto alle sue tecnologie del passato (vedi MFC aggiornato nelle varie versioni di Visual Studio) per cui il problema è in qualche modo contenuto. O almeno lo si può ragionevolmente sperare.

7. Presente: standard, compatibilità, frammentazione del mercato e rilevanza del vendor

Nonostante ogni vendor tenda a fare storia a sè, nel mercato esistono standard. Spesso l’aderenza di un prodotto ad uno o più standard appare più come uno specchietto delle allodole che non una garanzia concreta di interoperabilità (cioè non è così raro avere a che fare con implementazioni incompatibili di uno stesso standard), però la loro presenza è indubbiamente una cosa buona.

Generalmente la penso come Torvalds:

Standards are just papers. Yes, they’re important, but they are definitely not more important than anything else, and they are a lot _less_ important than some people seem to think.

Nel caso dell’esempio, i prodotti Silverlight non sono multipiattaforma come il codice HTML/Javascript prodotto in ASP.NET. WPF, non ne parliamo. In questo caso non mi riferisco all’ambiente di sviluppo, ma ai prodotti finiti. Silverlight è come Flash di Adobe: senza un plugin apposito, non va.

Poi si può discutere dei pro e dei contro (es: si ha o meno la certezza che i clienti usino solo Windows), ma credo non sia consigliabile sviluppare qualcosa per essere sfruttato via web con la stessa mentalità che si applica per dei prodotti desktop. O puntando ad una conversione totalmente indolore.

8. Futuro: notizie, rumors e altro

Si sa quando si comincia ad imparare, non quando si potrà smettere di farlo. In certe situazioni l’unica soluzione possibile è quella “brutta e sporca ma funzionante” per cui salta a priori qualunque tipo di analisi. Tuttavia, potendolo fare, ha senso scegliere e puntare su qualcosa che abbia un futuro.

Per cui è importante informarsi ed analizzare le informazioni che circolano, rumors inclusi. Ad esempio, leggere post come “WPF & Silverlight at risk from Microsoft’s passion for HTML5” può inquietare, soprattutto quando si dice che:

“A Twitter exchange with former Silverlight Product Manager Scott Barnes reported by The Register makes the following claims.

There is in-fighting between Microsoft’s Developer and Windows teams about the future of WPF, Silverlight and HTML5 as embodied in IE 9.”

Questo è un esempio di cosa intendo per rumor da prendere in considerazione prima di scegliere. Verificata l’attendibilità del rumor, lascio a voi tutte le considerazioni del caso.

9. Licenze, assistenza e TCO

Non voglio discutere e riaprire la solita discussione fra software FOSS e software chiuso/commerciale. Penso sia comunque ineccepibile che deve sussistere una relazione stretta fra costi e ritorno economico. Cioè non ha senso spendere dei soldi senza la certezza di rivederli indietro prima o poi, possibilmente con un certo margine.

Vorrei anche permettermi di far notare un fatto che ho imparato nel corso del tempo: il software può costare davvero poco o niente, ma i tecnici che devono seguirli comportano dei costi. Se una persona impiega un mese a rendersi produttiva su una data tecnologia, poco o tanto costosa che sia, quel mese non è stato produttivo in senso stretto ma lo sarà potenzialmente solo il mese dopo.

Rientriamo nuovamente nel discorso sulla curva di apprendimento, arricchendolo però del valore e dei costi di sviluppo, supporto ed assistenza, mantenimento, eccetera. In senso lato si parla di Total Cost of Ownership (TCO).

Tornando all’esempio è indubbio che Microsoft segua tutte quelle tecnologie ma a chi va la sua preferenza, quale è documentata meglio, quale impone costi espliciti ed impliciti minori?

10. Chiusura della piattaforma e restrizioni

Questo è un aspetto che reputo fondamentale. Salvo casi eccezionali, ad esempio nel caso di requisiti estremamente retrittivi, è sempre bene puntare a qualcosa che non imponga a noi stessi delle restrizioni.

Detesto i vendor lock-in (cfr. vecchio post), cioè quell’insieme di pratiche commerciali e tecnologiche messe in piedi dai vari produttori per “intrappolare” i cliente, in modo che ben presto questi ultimi non abbiano alternative se non continuare a rifornirsi dai primi.

Qui non parliamo di “brand vincente” o marketing particolarmente efficace, parliamo del fatto che man mano che ci si rifornisce da un solo fornitore per i suoi prodotti, poi si finisce legati ad esso mani e gambe.

La cosa curiosa è che spesso i lock-in sono subdoli: un prodotto potrebbe dichiararsi compatibili con mille standard salvo poi risultare un prodotto a sè stante, totalmente proprietario e volutamente incompatibile col resto del mondo.

Mi spiego meglio: ASP.Net produce codice HTML/Javascript e funziona tranquillamente e automagicamente anche sui gadget dei momento, smartphone e tablet, ma Silverlight e WPF?

Conclusioni

Con questo post spero di aver chiarito bene un punto: nel mondo della tecnologia, quella che garantisce a molti di noi la pagnotta a fine mese e che si rinnova ogni pochi mesi, è importante analizzare le opzioni sono tutti i punti di vista, compararle e scegliere solo se pienamente convinti o se non ci sono altre alternative praticabili.

E gli aspetti da valutare non sono affatto pochi.

Che ne pensate?

“Ho capito perché gli incapaci non riescono a consegnare il pacco: fanno affidamento ad un servizio informativo orrendo. In pratica ecco cosa è successo. L’indirizzo di Piska è lungo 36 caratteri (comprensivi di virgola e numero civico a due cifre). Il corriere ci ha comunicato che a loro è arrivata la bolla con solo i primi 30 caratteri dell’indirizzo da me scritto, risultando quindi incompleto.

Dunque da qualche parte nel software l’indirizzo viene tagliato a 30 caratteri senza tanti complimenti e mandato al corriere……bella schifezza. [...]“

Vale la pena analizzare questa situazione perchè ricorrente e ubiqua: per me è un antipattern vero e proprio.

Il flusso di elaborazione dei dati

Non so esattamente come sia andata, ma a occhio direi che nel caso di Piska si sia verificato un problema nella fase fra la compilazione cartacea dei dati di viaggio e la successiva immissione nel sistema, di norma effettuato dal personale specializzato che segue questo genere di mansione. Cioè i 36 caratteri scritti su un foglio sono poi stati “riversati” e gestiti erroneamente nel sistema automatizzato, che limitava quel numero a 30.

Nello spazio fra il desiderio dell’utente e la sua realizzazione può succedere di tutto.

Partiamo dall’inserimento nel sistema, solitamente qualcosa come una form web, collocato nel frontend. Ad esempio, può capitare che essa:

• non controlli il numero di caratteri e permetta di inserirne a volontà;
• li controlli ma permetta all’utente di forzarne comunque l’inserimento;
• li controlli solo nel momento dell’inserimento effettivo nel sistema, troncandoli automaticamente ed in modo silente.

Ora ripetiamo lo stesso discorso per ciascuno dei componenti attraversati nel flusso di elaborazione dei dati: pressochè tutti i sistemi di una certa complessità sono pensati e modellati in questo modo.

Per ragioni di comodità, pigrizia o chissà che altro, generalmente ogni componente tende a “fidarsi” del componente immediatamente precedente nella catena. Dopotutto:

“… perchè ripetere sempre gli stessi controlli in ogni componente attraversato dal flusso dell’elaborazione?”

Il problema è che ogni componente è una sorta di scatola nera rispetto a chi lo segue nella sequenza: come può un componente, diciamo alla fine di una catena, sapere che qualcuno prima di lui “si è mangiato” dei caratteri?

Ogni violazione della catena di responsabilità (Chain-Of-Responsibility pattern) dovrebbe provocare l’immediata interruzione dell’elaborazione con relativa segnalazione dell’errore all’utente. In sostanza si dovrebbe ottenere una transazione di tipo atomico: o tutto funziona o l’ordine viene rifiutato in blocco.

Tuttavia, cosa succede se chi deve controllare non trova l’errore? Cosa succede se, come spesso accade, è il solo frontend ad effettuare controlli, a rappresentare il primo e più importante fronte di sicurezza di un sistema?

Beh, gli effetti sono noti: spesso si ha notizia di siti “bucati”, ad esempio tramite Cross-site scripting (XSS), che espongono dati sensibili e componenti critici del sistema, che dovrebbero rimanere nascosti e proteti nel backend, alla mercè dell’attaccante.

Nel caso di Piska, sarei propenso a credere che qualcosa nel frontend abbia troncato l’indirizzo da 36 a 30 caratteri, automaticamente ed in modo silente (orrore!), prima della registrazione nel DB. Questo perchè di solito i DBMS sono estremamente pignoli nel rifiutare in toto un inserimento, nel caso di una violazione sulla dimensione massima di un campo.

O almeno questa è una mia supposizione, frutto dell’esperienza come sviluppatore web specializzato nel backend.

Trust no one!

Ricordo il giorno in cui, quasi un decennio fa, l’amico Cubo mi accennò per la prima volta a Qmail, celeberrimo server sicuro di posta elettronica ideato da Daniel J. Bernstein, noto anche con le iniziali DJB.

Particolarità di questo software, pensato per sistemi operativi UNIX e UNIX-like, è l’aspetto della sicurezza. Da Wikipedia:

In contrast to sendmail, qmail has a modular architecture composed of mutually untrusting components; for instance, the SMTP listener component of qmail runs with different credentials than the queue manager, or the SMTP sender. qmail was also implemented with a security-aware replacement to the C standard library, and as a result has not been vulnerable to stack and heap overflows, format string attacks, or temporary file race conditions.

Questo il punto: ogni componente non si fida degli altri e applica tutti i controlli possibili per individuare problemi nei dati.

L’obiezione canonica a questo approccio, che definirei vagamente paranoide, di solito riguarda le prestazioni:

…ma se nessuno si fida dell’altro, allora l’intero sistema sarà rallentanto dai continui, ripetuti ed estenuanti controlli!

Invece no:

When it was released, qmail was significantly faster than Sendmail, particularly for bulk mail tasks such as mailing list servers. qmail was originally designed as a way for managing large mailing lists

Tanto per cominciare non serve effettuare tutti i controlli possibili, anche quelli chiaramente superflui (cfr. vecchio post), ma agire in modo che i componenti possano fidarsi. E prima ancora che i componenti possa fidarsi, è il programmatore che deve fidarsi degli strumenti: Bernstein ha iniziato buttando e riscrivendo quello di cui lui stesso, in qualità di programmatore, non si fidava:

Write bug-free code.

I’ve mostly given up on the standard C library. Many of its facilities, particularly stdio, seem designed to encourage bugs. A big chunk of qmail is stolen from a basic C library that I’ve been developing for several years for a variety of applications. The stralloc concept and getln() make it very easy to avoid buffer overruns, memory leaks, and artificial line length limits.

Il passo dopo è evitare di ripetere e ripetere il lavoro, convertendo i dati da un formato interno all’altro: capita spesso che ogni componente, specialmente quando c’è di mezzo del middleware proprietario, necessiti di convertire i dati in un qualche formato o struttura interna particolare. Se tutti i componenti invece usano la stessa rappresentazione dei dati, senza continue conversioni, senza continui controlli, ecco che le prestazioni aumentano, così pure il livello di sicurezza dell’intero sistema.

Come direbbe Bernstein:

Don’t parse.

I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces.

The essence of user interfaces is parsing: converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data.

When another programmer wants to talk to a user interface, he has to quote: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data.

This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.

When the original data is controlled by a malicious user, many of these bugs translate into security holes. Some examples: the Linux login -froot security hole; the classic find | xargs rm security hole; the Majordomo injection security hole. Even a simple parser like getopt is complicated enough for people to screw up the quoting.

In qmail, all the internal file structures are incredibly simple: text0 lines beginning with single-character commands. (text0 format means that lines are separated by a 0 byte instead of line feed.) The program-level interfaces don’t take options.

Ovviamente poi DJB cita il principio KISS, “Keep It Simple, Stupid”: più le cose sono semplici, più sono facili da comprendere, verificare e manutenere. Occam docet.

Che ne pensate?

Ovviamente l’intento del post è ironico…

Hollywood? No, davvero

Non sono una una macchina nè permetterò mai che una di esse mi renda un suo schiavo: paragonarmi ad un computer o preannunciarmi che prima o poi mi trasformerò in esso “se continuo così” è ridicolo. Idem lanciarsi in improponibili previsioni in merito, anche se Hollywood la pensa ben diversamente sul filone uomo-macchina (cfr. Matrix, Terminator).

Io sono un informatico e, per la gizilionesima volta, l’informatica non coincide affatto e solamente col progettare ed usare computer:

“What would we like our children – the general public of the future — to learn about computer science in schools? We need to do away with the myth that computer science is about computers. Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes or chemistry is about beakers and test tubes. Science is not about tools, it is about how we use them and what we find out when we do.” (M. R. Fellows e I. Parberry, poi ripresa da Edsger W. Dijkstra)

Aggiustare un computer è un effetto collaterale del conoscere quello strumento, non lo scopo dell’esistenza professionale di un informatico e, probabilmente, neppure quella di un tecnico dell’assistenza IT. Il fatto che io sappia “usare un computer” non implica che debba (ri)conoscere istantaneamente qualunque sistema elettronico. Nè che lo sappia usare od aggiustare con la stessa disinvoltura di un protagonista di un film d’azione, che utilizza qualunque arma gli capiti a tiro, incluse quelle aliene (cfr. Independence Day).

Non sono un “(piccolo) mago del computer” perchè di magia non ce n’è. Di nuovo, semplicemente conosco gli strumenti scientifici e tecnologici del mestiere e ne ho fatto una professione:

“Any sufficiently advanced technology is indistinguishable from magic.” (Tre leggi di Clarke)

Analogamente, nonostante le perssime abitudini umane ad antropomorfizzare ogni cosa (cfr. pallone Wilson in Cast Away), i PC sono essenzialmente oggetti, entitità inorganiche, non viventi e non sperimentano sensazioni e sentimenti. Quindi non odiano gli incauti padroni, nonostante i guai che questi ultimi possono provocare. Al massimo siamo noi informatici a non raccapezzarci dei danni da sistemare in seguito a qualche “Incontro ravvicinato” utente-macchina e a sperimentare biechi sentimenti di vendetta nei riguardi dei bipedi-carnefici.

Questione di etichette…

Quanto ai modi per definirci, geek e nerd, ormai “mainstream” come termini, non sono sinonimi di informatico, anche se esiste una certa correlazione causale fra queste etichette. Se anche mi riconoscessi in esse, nell’accezione negativa intendo, non chiederei comunque la solidarietà o la commiserazione del prossimo: non sono un cucciolo di cane maltrattato dalla società nè un Quasimodo rinchiuso in una torre di una cattedrale virtuale.

Non sono più fissato di molte altre persone che parlano ossessivamente dei loro problemi, delle loro fortune, delle loro famiglie, dei loro hobby ed interessi. Anzi, non mi capacito proprio del perchè parlare senza sosta di argomenti come la famigerata combo donne-calcio-motori sia considerato “normale”, mentre interessarsi di computer sia considerato innaturale, anche se magari non ne si parla mai in pubblico.

Come tutte le categorie professionali, anche gli informatici indugiano in battute pietose e comunque comprensibili solamente dai propri “pari”. Avete mai sentito battute in slang fra studenti di medicina? Stessa cosa. Con problemi con i familiari analoghi ai “nostri”.

Di professione sono programmatore, perchè mi piace ed anche per camparci, ma non so fare e non faccio solo quello. Non basta fare o sentirsi programmatori per definirsi anche informatici, anche se certamente la cosa aiuta. Di certo non sono un “softwarista“: amo forgiare neologismi, ma non ne userei mai uno così orribile, riduttivo, impreciso, per descrivere chi io sia.

Chi mi fa notare che scrivere codice sia un gioco da ragazzi, un lavoro facile, evidentemente non conosce bene questo mondo. Vero, non tutti i progetti sono così difficili, ma generalmente scrivere codice è una fase operativa avanzata rispetto ad altre, come la progettazione, dove iniziano i mal di testa.

“In fact, my main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do. (Donal Knuth)”

A chi mi fa notare che programmare, in fondo, non sia un “lavoro” o che sia perfino sovrapagato (in Italia!?!) rispetto ad altre mansioni, spesso più “manuali”, mi viene da sorridere. Detto ciò, considerato che lavorare nell’informatica non è come accedere in una casta chiusa, non vedo perchè chi ha preparazione e know-how non possa ambire in alto, anche econonomicamente. Come per tutte le altre professioni, del resto. Ennesima variante di un classico aforisma d’esempio (altra variante):

Do You Know Where To Hit The Hammer?

A company has developed the latest and greatest monster widget maker. They’ve sent out invitations for the grand reveal to the world’s press and major business players. 15 minutes before the coming out party is to start, with the grandstands bursting at the seams, television cameras trained on the dignitaries and company executives, and the place at full-tilt frenzy, the widget maker shuts down. No amount of fiddling by the operators could get the machine fired up. In a panic the company president remembers that the chief engineer of the machine had retired the week before. The president gets the engineer on the phone and pleads for him to come in and get the machine working. The engineer says he’ll fix it but he’s charging $10,000. The president readily agrees.

5 minutes later the engineer shows up. He looks over the machine, taking special note of several areas on the machine. He then takes a hammer out of his bag and hits one of the spots with a might whack! The machine immediately springs to life, producing widgets like there’s no tomorrow. The engineer puts the hammer back in his bag, walks up to the president and says “That will be $10,000″. The president looks at him and screams “$10,000??? You spent two minutes here just to hit it with a hammer!!!!”. The engineer pointedly looks at the president and says “I threw in the hammer hit for free. The $10,000 was for knowing where to hit it.”.

Che ne pensate?

“Avete consigli su come approcciare lo studio di un’applicazione legacy su cui dovrete lavorare ed effettuare modifiche, considerando che si tratta di un’infinita schiera di file salvati in n+1 cartelle, che si includono a vicenda, senza uno straccio di documentazione né commenti esplicativi?”

Domanda molto interessante, a cui vorrei rispondere ora, seppur brevemente…

L’approccio al problema

A chi non è mai capitata una cosa del genere, ossia avere a che fare con codice di terzi, magari legacy? Ovviamente la risposta è banale – tutti! – e, salvo rari casi, il compito non è mai una passeggiata.

Il problema non è solo metterci le mani, quanto capirlo e comprenderlo per poi decidere il da farsi.

Questo tipo di strategia però non sempre è possibile ed è abbastanza normale dover ottenere in fretta dei risultati – quindi modificare direttamente quel codice! – senza avere il tempo di effettuare un’ispezione accurata. Un po’ come buttarsi a scrivere un nuovo programma senza neppure avere un’idea di fondo di quello che dovrà fare e soprattutto come dovrà farlo.

Esiste poi una sorta di atteggiamento spocchioso e terribilmente comune nei programmatori che si approcciano al lavoro di terzi ed è quello di partire prevenuti nei confronti degli altri, salvo poi peggiorare facilmente nel giudizio man mano che va avanti nella lettura: al minimo errore individuato – reale o presunto che sia -, al minimo commento incompleto o inesatto, alla minima imprecisione nell’indentazione, ecco che iniziano i mugugni del programmatore di turno verso “chi ha fatto quello scempio“.

Le motivazioni di questo tipo di atteggiamento sono le più disparate: dal “io queste cose le so fare meglio” fino al diventare una buona scusa per giustificare ulteriori ritardi (“è talmente ingarbugliato che in pratica lo sto riscrivendo!”).

Per esperienza, direi di concedere al codice altrui ed al suo autore il beneficio del dubbio, almeno finchè non si è conclusa un’attenta e relativamente lunga fase di ispezione. Di rimando, mai fidarsi ciecamente delle impressioni di un programmatore alle prese con codice non suo, almeno finchè non si è sporcato le mani davvero, in profondità. Anche perchè, finchè un dev non arriva ad un certo livello di intimità con del codice, di norma non può sapere quanto ne dovrà cambiare: in altre parole, a seconda del singolo progetto e a fronte anche di migliaia e migliaia di potenziali righe di codice da visionare, quelle effettivamente da modificare potrebbero essere molto poche. Un conto sono valutazioni oneste, frutto di indagini serie e prolungate nel codice altrui, un conto sono supposizioni ed illazioni “spannometriche”, emesse in fretta e furia e, tavolta, anche con una certa malizia di fondo.

Di certo leggere poche righe di codice e, senza nemmeno averle capite, decidere di riprogettare il codice da zero è una scelta radicale e spesso controproducente: posso capire quando il codice altrui fa veramente pietà e non c’è modo per manutenerlo, ma il capriccio di volerlo rifare a tutti i costi no. Non c’è sindrome “Not Invented Here” (NIH) o volontà di dimostrarsi più bravi che tenga.

Il problema: approcciare l’ignoto

Il problema più grosso con il codice è l’ignoto. L’ignoto è codice altrui, che vedete per la prima volta, e perfino codice che voi stessi avete scritto anni prima e che non avete più toccato da eoni.

È un ammasso minaccioso di righe che dovete comprendere prima ancora di poterle modificare. Naturale quindi che, impaurito, qualcuno si ribelli a questa situazione e, piuttosto di affrontarla, opti per ripartire da zero. Inoltre, come direbbe Sposlky:

It’s harder to read code than to write it.

Da questo punto di vista i programmatori sono l’esempio per antonomasia di persone che non sono mai contente fino in fondo e che bisogna in qualche modo controllare: è normale che un dev arrivi ad un certo punto del suo lavoro e pensi/provi insistentemente a ripartire da capo – un errore generalmente gravissimo! -, figuriamoci se il codice iniziale l’ha scritto qualcun altro.

Prima regola per affrontare l’ignoto: non andare in panico, non tirare i remi in barca prima di averlo affrontato e possibilmente compreso, anche solo parzialmente. Sono le fasi iniziali quelle critiche: l’autocontrollo è essenziale. Non appena si comincia a capire qualcosa, la paura passa di colpo, automagicamente.

Un approccio personale

Dopo aver sconfitto il demone della riscrittura from scratch, è fondamentale circoscrivere ed analizzare l’ignoto. Ognuno di noi sviluppa col tempo le sue personali strategie per raggiungere i suoi scopi.

Il mio è relativamente semplice ed è sintetizzabile in analizza, circoscrivi e migliora, ripeti.

1. Analizza

Analizzare il codice significa volerlo capire con un certo livello di dettaglio. Se le dimensioni del codice e dell’eventuale documentazione a corredo sono contenute, apro il codice in un IDE e provo a capire da solo.

Molto più spesso uso invece Doxygen, che considero alla stregua di un coltellino svizzero. Da Wikipedia:

“Doxygen è una applicazione per la generazione automatica della documentazione a partire dal codice sorgente di un generico software. È un progetto open source rilasciato sotto licenza GPL, scritto per la maggior parte da Dimitri van Heesch a partire dal 1997.

Doxygen è un sistema multipiattaforma (Windows, Mac OS, Linux, ecc.) ed opera con i linguaggi C++, C, Java, Objective C, Python, IDL (versioni CORBA e Microsoft), Fortran, PHP, C#, e D. Nell’ambito del C++, è compatibile con le estensioni Qt.

È il sistema di documentazione di gran lunga più utilizzato nei grandi progetti open source in C++. Due esempi per tutti, sono l’adozione di doxygen da parte di ACE e KDE. In Java invece, la posizione leader viene meno, in virtù della presenza del concorrente Javadoc.

Il sistema estrae la documentazione dai commenti inseriti nel codice sorgente e dalla dichiarazione delle strutture dati.”

Non solo è utile per creare documentazione partendo dal codice, documentato tramite opportuni tag, ma è estremamente efficace nell’estrarre anche altro.

Ad esempio, recentemente ho deciso di dare un’occhiata al codice di Doom 3 di ID Software, rilasciato finalmente sotto licenza GPL e pubblicato sul sito GitHub in questo repository pubblico.

Non è certamente un progetto-giocattolo ed infatti richiede una buona competenza tecnica per maneggiarlo, nonostante sia generalmente ben scritto (in realtà avrei alcune riserve da programmatore a programmatore – vedi sezione precedente -, ma non è la sede giusta per farlo).

Capirci qualcosa non è quindi stato molto facile, ma Doxygen si è nuovamente rivelato utilissimo per esplorare il codice cercando di capire come è stato strutturato – non sempre l’organizzazione dei file è intuitiva nè i programmatori-autori lasciano spesso file di spiegazione esaustivi sull’argomento -.

Premesso che non volevo studiare il codice a fondo, ma solamente dargli un’occhiata rapida, ma con Doxygen questa “passeggiata” mi è diventata decisamente più godibile.

Usare Doxygen poi è veramente facile: basta installarlo, lanciare l’interfaccia grafica (GUI), configurare pochi parametri e fa tutto lui. Se poi avete installato anche la suite Graphviz, potrete attivare l’opzione per ottenere i diagrammi , anche simil-UML, con dot.

Un breve riassunto, step-by-step:

1. Configurazione iniziale in Doxygen: nome progetto, directory di lavoro, eccetera	2. Configurazione della generazione dei diagrammi
3. Abilitazione della ricerca ricorsiva nelle sottodirectory di quella dove risiede il codice da analizzare	4. Avvio del programma (Run)
5. Completamento operazioni	6. Apertura dei risultati in un browser: si notino i diagrammi di ereditarietà e di collaborazione fra classi

Dopo un’oretta buona di processamento – il codice è relativamente complesso e denso di informazioni estraibili – ho quindi potuto leggere i risultati direttamente in un browser. Trovo molto comodo che sia possibile includere nella documentazione generata da Doxygen anche i sorgenti stessi. In un colpo si riesce a:

• osservare il progetto nella sua interezza, a dispetto del suo essere eventualmente sparpagliato in mille file in mille directory diverse;
• esplorarlo in vari modi: per classe, namespace, e così via,
• leggerlo in un modo esteticamente piacevole: Doxygen uniforma tutto, alla faccia dei file/sorgenti scritti in modo diverso;
• analizzarlo in modo efficiente: viva gli hyperlink per passare da un file ad un altro, da una funzione all’altra senza perdere tempo e con la possibilità di usare il tast “Indietro” del browser!.

Inoltre Doxygen stesso è efficiente nel senso che se modificate un file, di norma non rigenererà da zero la documentazione, ma solo la porzione di essa che è toccata dai cambiamenti nel codice.

2. Circoscrivi e migliora

Ogni progetto di una certa taglia è il frutto del lavoro di uno o più individui nel corso del tempo. Il risultato è che raramente il suo codice appare ed è omogeneo.

Realisticamente, soprattutto per programmi con una certa anzianità, ci si trova con una pletora di file, ognuno col suo codice scritto in modo “particolare“: non di rado capita di trovare differenze abissali fra un file ed un altro nello stesso progetto.

In C e C++ si parla di compilazione per unità singole per indicare il modo con cui avviene normalmente la compilazione, ossia file per file. In sostanza, al netto del significato reale, ogni file sorgente fa storia a sè durante quella fase. Avviene la stessa cosa anche in fase di scrittura: file diversi fanno storia a sè. Uno stesso programmatore nel tempo può cambiare in modo considerevole il suo stile di scrittura, al punto da non riuscire a identificare come suo del codice che ha sviluppato molto tempo prima. Hic sunt leones…

Dopo aver capito cosa fa grossomodo un progetto si passa all’analisi per “sottosistemi”, se è possibile individuarne dei limiti: di solito i file sorgenti nei progetti di una certa dimensione sono raggruppati in qualche modo, per agevolare lo sviluppo e la manutenzione di parti logicamente legate.

Ad esempio tutto quello che riguarda l’accesso ad un filesystem potrebbe essere stato posto in una directory fs oppure tutti i file potrebbero risiedere nell’unica directory con gli altri sorgenti ma essere rapidamente individuabili da un prefisso fs nel nome. Nel caso invece tutto fosse alla rinfusa, nuovamente, Doxygen torna utile per capire le interrelazioni fra file e funzioni.

A quel punto, in perfetto stile divide et impera, si può approcciare l’ignoto dedicandosi ad un “sottosistema” per volta, cercando di comprenderne la struttura ed il ruolo per poi modificarlo se è il caso.

Durante questa fase, se è il caso, di solito provo anche a ridurre il numero di file, per renderlo maneggiabile: detesto maneggiare una miriade di piccolissimi file ognuno con una classe di pochissime righe (una certa filosofia nel mondo Java sembra favorire questo approccio). Per cui si procede con una riorganizzazione per passi dei file e poi al refactoring del codice vero e proprio.

L’idea è capire cosa fa un pezzettino del programma ignoto e, compreso, ridurne le dimensioni per rendere le successive modifiche più efficienti. Accorpare e semplificare sono le due parole magiche:

“La perfezione è raggiunta non quando non c’è più niente da aggiungere, ma quando non c’è più niente da togliere. (Antoine de Saint-Exupéry)

Durante questa fase, procedendo per passi piccoli ma decisi, vale la pena uniformare il codice, ossia applicare e riapplicare un manuale di stile e delle coding convention, precisi e predeterminati.

A questo punto il trucco si ripete, ossia si riparte dall’analisi e si continua finchè l’ignoto diventa qualcosa di compatto, manutenibile ed assolutamente non spaventoso.

Che ne pensate?

Alcuni dei consigli sono emersi qua e là, nei miei post passati, ma ho notato di aver trascurato del tutto un “fattore di crescita professionale” molto importante, che mi si è rivelato utilissimo: i “modelli di riferimento“.

Modello?

È indubbio che esistano tanti modelli di programmatori quanti sono i programmatori stessi ma, come è lecito aspettarsi, non tutti sono altrettanto efficaci e, di conseguenza, non tutti meritano di essere seguiti. Così come avviene, del resto, per i modelli di sviluppo software.

Non è una semplice questione di conoscenza: un programmatore da prendere come esempio, come “modello di riferimento“, non è semplicemente qualcuno che ne sa più di noi.

È piuttosto qualcuno che ha le idee sufficientemente chiare per svolgere un determinato compito in modo ordinato, preciso e se possibile anche elegante.

Se poi la sua conoscenza è estremamente vasta ed è perfino in grado di insegnarla in modo comprensibile a terzi, tanto meglio. Tuttavia non è una condizione imprescindibile per essere un “modello valido“.

Un modello non è necessariamente (anche) un buon maestro

Esattamente: un modello non è per forza un docente, professore, … ma chiunque può esserlo o diventarlo nell’atto di svolgere qualcosa.

Ad esempio, una decina e più di anni fa, all’inizio della mia carriera universitaria, ricordo di aver visto il codice C per un progetto d’esame, scritto da un mio compagno di università che all’epoca era certamente già ben più esperto di me.

L’esercizio da svolgere non era particolarmente complicato ma lui lo aveva svolto in modo terribilmente elegante: gli spazi dove servivano, tutte le parentesi al loro posto, i commenti dove e solo se servivano, eccetera.

Era così ben scritto che riuscivo a capire al volo cosa facevano alcune funzioni della libreria C, all’epoca a me ignota in molti punti, libreria che non è mai stata celebre per la sua chiarezza e “intuitività“.

Man mano che leggevo quel codice continuavo a ripetermi:

“Wow! Questo sì che sa come si fanno le cose bene!”

Quel giorno ho imparato il concetto di “stile” nella programmazione, per giunta nella sua accezione positiva. Non un libro, non un docente chiamato ad insegnarmi a programmare, ma uno studente come me ed attraverso il suo codice ben scritto.

Quel giorno trovai un modello da seguire, a cui ispirarmi e per giunta senza che questi ne fosse a conoscenza.

Quel giorno formulai quest’altra semplice (banale?) euristica:

“Se qualcosa ti fa esclamare più di due volte ‘Wow!’ mentre la osservi, allora è fatta dannatamente bene, almeno in parte!”

Come ho avuto modo di scrivere più volte, non sono un guru e quel poco che so lo devo all’aiuto, diretto ed indiretto, di molte persone. Non potendole ringraziare una ad una – anche se lo meriterebbero – le ringrazio tutte in blocco, “ecumenicamente”.

Non esiste un modello unico ed universalmente valido di programmatore!

Sono convinto che ogni programmatore deve e può crearsi una sua “personalità programmativa“, magari costruita a partire da più modelli validi di riferimento.

In altre parole il programmatore alle prime armi può crescere professionalmente in fretta se impara ad individuare ed a seguire modelli validi, che può trovare quotidianamente e senza che debba sussistere per forza un legame esplicito tipo maestro-discepolo. Possono bastare anche le sole opere, debitamente osservate ed analizzate, come nel mio caso.

Seguire non è copiare spudoratamente, piuttosto assimilare solo le parti che si ritengono davvero buone, perfino da più persone contemporaneamente. Il risultato è appunto una “personalità programmativa” in cui si annidano le esperienze altrui.

Ricordo quando, sempre in università eoni or sono, impararai a progettare e strutturare un sito in certo modo, semplicemente osservando alcuni miei amici intenti a scriverne uno ed a discutere fra di loro sul da farsi: non scambiai nemmeno una parola sull’argomento con loro, però in qualche modo furono miei maestri e io un loro padawan.

Non esistono solo “casi di successo”

Sulla strada per diventare buoni programmatori si trova di tutto, comprese soluzioni eccellenti e in opposizione. A quel punto entrano in gioco altri fattori come ad esempio il proprio “gusto“.

Quando mi son trovato in una situazione del genere, cioè dovendo scegliere fra più opzioni contrapposte (es: due programmatori-modelli che risolvono un problema in modo diametralmente opposto e/o mutualmente esclusivo fra di loro), ho optato per quella più semplice, anche solo apparentemente: il “rasoio di Occam” rappresenta anche un’ottima euristica per scegliere.

Spesso, come è logico supporre, mi è capitato di tornare sui miei passi, ossia rivedere e scartare – a fatica – alcune mie “fissazioni”.

Una soluzione che si è rivelata buona una volta non significa che lo sarà anche in futuro. Idem per le persone.

Fidarsi ciecamente di qualcosa o qualcuno o, peggio, rifiutare a priori il resto è un sintomo di fanatismo, da rifuggire. Il mondo cambia e insieme a nuovi problemi emergono anche nuove soluzioni: rimanere ancorati, cristallizati a qualcosa o qualcuno è rischioso e quindi sconsigliabile.

Ad esempio, per tornare con i piedi per terra, detesto profondamente l’lo stile di indentazione K&R perchè ritengo che rovini l’ordine ed ostacoli la leggibilità del codice rispetto ad altri stili come l’Allman. Eppure, osservando il codice scritto da persone competenti, mi sono ricreduto. Inoltre ci sono casi in cui bisogna compattare il codice il più possibile, ad esempio pubblicando il codice su delle riviste. Ho quindi imparato a tollerarla.

Migliorare!

L’idea alla base è provare a riflettere non solo sul cosa imparare, ma anche sul come: come accrescere le proprie conoscenze, come migliorarsi, come diventare più efficienti, eccetera.

Questa è la parte inizialmente più difficile ma è anche quella che sul medio-lungo termine garantisce i risultati migliori.

Saper individuare e seguire dei modelli validi è un buon modo per favorire questa crescita personale e professionale.

Che ne pensate?

Kranzberg’s laws of technology

1. Technology is neither good nor bad; nor is it neutral.
2. Invention is the mother of necessity.
3. Technology comes in packages, big and small.
4. Although technology might be a prime element in many public issues, nontechnical factors take precedence in technology-policy decisions.
5. All history is relevant, but the history of technology is the most relevant.
6. Technology is a very human activity – and so is the history of technology.

Sulle prime ho riso, poi ho riflettuto, quindi ho convenuto con il loro autore.

1. “La tecnologia non è buona nè cattiva; ma neppure neutrale”

Interessante come punto di vista: la tecnologia risolve bisogno – reale o creato – e per quanto possa essere apparentemente neutra in sè, gli effetti non lo sono.

Verrebbe da citare Alfred Nobel, inventore della dinamite e ideatore del celeberrimo premio che porta il suo nome: grande invenzione ma che a seconda di come viene impiegata ha avuto e ha effetti positivi o negativi, certamente non neutri.

Curiosamente la storia è fatta di scoperte ed invenzioni nate per scopi militari e poi impiegate successivamente anche per usi civili. Di sicuro ogni invenzione spinge avanti il progresso e non si può più tornare indietro, fare finta cioè che non sia mai esistita.

2. “L’invenzione è la madre della necessità”

Questa frase ad effetto mi piace molto e suona ambigua. Personalmente la interpreto come un “l’invenzione crea il bisogno“, nel senso che molte invenzioni moderne nascono col preciso intento di creare nuovi bisogni e quindi spingere l’acquisto dei frutti derivanti da esse. La necessità intesa quindi in senso consumistico.

In realtà, la storia insegna, l’invenzione spesso appare come scoperta casuale e non voluta di ricerche con altri fini. L’esempio prediletto dagli spammer: il Viagra,

“inizialmente studiato per la cura dell’angina pectoris”

In altri casi l’invenzione è invece la risposta a qualche problema specifico o a qualche “prurito” personale:

“Every good work of software starts by scratching a developer’s personal itch.” (The Cathedral and the Bazaar, E.S. Raymond)

3. “La tecnologia arriva in pacchetti, grandi e piccoli”

Altra frase ad effetto, dai molti significati.

Perchè una tecnologia si diffonda, deve essere possibile innanzitutto imbrigliarla, controllarla, trasformarla in qualcosa di pratico e riproducibile, dosarla, inscatolarla per poterla infine vendere in base a qualche criterio, incluso certamente quello dimensionale.

Un’altra interpretazione, abbastanza banale, è relativa al fatto che spesso i primi prodotti di una tecnologia che compaiono sul mercato sono relativamente grossi (es: primi cellulari e, volendo, perfino l’ENIAC!) e man mano vengono miniaturizzati, arrivando a stare quindi in pacchetti molto piccoli e maneggevoli.

Infine, come non citare i pacchetti intesi come unità di trasporto di informazioni, quindi le moderne reti di telecomunicazioni di cui Internet è certamente l’emblema.

Chissà quante altre interpretazioni sono possibili partendo da questa frase…

4. “Anche se la tecnologia potrebbe essere un elemento primario in molte discussioni pubbliche, fattori non-tecnici prendono il sopravvento nelle decisioni che riguardano l’uso della tecnologia”

Dato che gli effetti della tecnologia non sono mai neutri, è ovvio che il suo uso vada discusso ed opportunamente regolamentato. Quindi molti altri fattori non-tecnici hanno pressochè spesso il sopravvento su di essa:

Kranzberg’s Six Laws of Technology, a Metaphor, and a Story

“Fourth Law: [...] many complicated sociocultural factors, especially human elements, are involved, even in what might seem to be ‘purely technical’ decisions.” “Technologically ‘sweet’ solutions do not always triumph over political and social forces.”

Un recente esempio “scientifico”:

US Government tries to restrict publication of details on avian flu virus that spreads among mammals

Although avian flu viruses have infected humans in the past (often with lethal effect), so far, these infections have come directly from birds. Over this past summer, however, researchers presented disturbing results at a scientific meeting. By growing the avian H5N1 virus in mammals for several generations, they had evolved a strain that can spread among mammals (ferrets, in this case) simply through the air. Additionally, researchers identified the mutations that enabled the virus to do so–the kind of information that would be enough to allow any competent molecular biologist to create an exact duplicate.

Like any scientists, these ones want to publish their results, but that’s where things are getting messy. The US National Science Advisory Board for Biosecurity has asked both Nature and Science to “delete details regarding both scientific methodology and specific viral mutations before publishing.” The journals recognize why the NSABB is concerned, but they also both feel that responsible researchers will need to know these details if they’re to effectively study the risk of an H5N1 pandemic.

Currently, both have issued statements that they’re considering the requests, but haven’t yet decided how to proceed.

In questo caso l’aspetto scientifico, che di norma anticipa un eventuale sviluppo tecnologico, scatena reazioni pubbliche che arrivano addirittura alla richiesta di censura (che sempre un grosso errore: cfr. effetto Streisand). Oltre a instillare dubbi sul buon senso di una tale ricerca:

“Serviva davvero mutare il virus o lo scopo era semplicemente ottenere una pubblicazione su una rivista peer-reviewed di prestigio?”

Ogni invenzione, ogni “breakthough” tecnologico comporta qualche sconvolgimento, non necessariamente negativo per tutti.

La Rete, si dice da tempo ad esempio, sta uccidendo l’editoria “classica” e si discute di come arginare questo fenomeno, addirittura a colpi di leggi e leggine. Ma se si valuta nel complesso umano, la sua sola esistenza ha portato anche molti effetti positivi, incluso l’avvicinare un certo grado di istruzione a persone che altrimenti ne resterebbero totalmente privi.

5. “Tutta la storia è rilevante, ma la storia della tecnologia è la più rilevante”

Il fatto che uno storico, in seguito storico della tecnologia, emetta questo giudizio non mi sorprende più di tanto: si potrebbe dire che tira l’acqua al suo mulino. Però, a ben vedere, ogni aspetto umano è toccato da benefici “tecnologici”, frutto di innovazioni vere e proprie. Perfino negli aspetti umanistici fiori fior di letterati, poeti, scultori e artisti hanno innovato, ossia spinto più in alto l’asticella del progresso.

Tuttavia, la Storia raccontata e studiata a scuola tende più a parlare di fatti, date e persone che non a focalizzarsi sul progresso in quanto tale. Non che sia un male, ma ogni tanto è bello scoprire le “innovazioni”, perfino quelle più strane. Ricordo con piacere quando da giovincello mi fu spiegato che fu Napoleone a imporci, fra le varie cose e per editto, che i cimiteri fossero collocati fuori dalle mura cittadine (anche) per motivi igienico-sanitari oltreché politici-ideologici.

Non credo che la storia della tecnologia avrà mai il suo spazio a scuola, però condivido la sua importanza fondamentale per il genere umano.

6. “La tecnologia è un’attivà veramente umana – e così pure lo è la storia della tecnologia”

Esiste una specie di velato e sotterraneo disprezzo reciproco fra i propugnatori della scienze e quelli delle discipline umanistiche. I primi reclamano il progresso come loro bottino di guerra, mentre i secondi la cultura. In realtà tutte queste cose non sono altro che attività umane, spesso intimamente legate le une alle altre al punto che se esiste un confine che le separa, esso è certamente molto labile.

In tutto ciò la tecnologia è un esempio delle capacità del genere umano, qualcosa che ci distingue dalle altre specie animali e ci ha garantito anche la supremazia a livello planetario.

Di rimando, studiare la storia della tecnologia è importante per capire la storia umana e, forse, per favorirne nuovi impulsi. Non a caso su Slashdot è apparso recentemente questo articolo:

Want To Get Kids Interested In Programming? Teach Them Computer History

“With poor IT teaching putting kids off pursuing a career in the computing it is time to look for a new approach. Taking kids back to the time of computing pioneers like John Von Neumann and the first machines — the likes of the Z3, the Eniac and the Colossus — would both inspire them and help get over the fundamentals about how computers work, argues silicon.com.”

Che ne pensate?

Forse una particolare forma di intelligenza? Forse la coordinazione nell’uso degli strumenti di input? Forse la tenacia nell’imparare e nel contempo piegarsi poco a poco al modo di funzionare di una macchina?

Dipende da caso a caso ma, dovendo generalizzare, credo che nessuna di queste caratteristiche sia più importante della mancanza di possibilità e di volontà di osare.

Sani errori di gioventù

Ricordo benissimo quando intorno ai 16 anni, insieme a Windows 95 OSR2, comparve la misteriosa FAT32. Non sapevo cosa fosse realmente, non ne capivo necessità ed uso, ma volevo provarla a tutti i costi.

Tentai quindi la conversione da FAT16 a FAT32 del disco di sistema con il programma fornito dal sistema operativo, ma qualcosa andò storto. Problema: quello era anche il PC di mio papà. Follia giovanile è anche fare qualcosa senza sapere come e perchè: non avevo idea dell’importanza dei dati personali e quindi del rischio di comprometterli o perderli per una “stupida prova“, invasiva e distruttiva.

Le conseguenze furono migliori delle attese, nonostante la sacrosanta furia genitoriale nei miei confronti: un amico di mio papà, il nostro esperto locale di PC, salvò capra e cavoli, recuperando i dati con chissà-quale-strumento e tutto tornò a posto, seppure ancora con la FAT16.

Ovviamente non finì lì il discorso: ci riprovai, fallendo miseramente per la seconda volta.

Questa volta però, invece di darmi per vinto e nella speranza di evitare danni ben più gravi, cercai in tutto quello che avevo – all’epoca la documentazione erano per lo più le riviste specializzate con CD allegato – e riuscii in pieno nel mio intento: ora avevo un disco formattato in FAT32.

Quel giorno andai a letto spossato ma felice. Per evitare guai seri – la reiterazione di un misfatto li induce -, stavolta avevo dovuto imparare cosa fosse davvero un filesystem, cosa differenziasse la FAT32 dalla FAT16, cosa fosse e come usare Partition Magic.

Cosa è ed a cosa serve una sandbox

Ripensando a quanti danni e quanti rischi mi sono accollato per imparare sporcandomi le mani – non crederete certo che mi sia limitato alla FAT32, vero? -, non mi sento di condannarmi. Affatto.

Col senno di poi, tuttavia, mi accorgo solo ora di quanto ho rischiato. Quando commisi quegli errori, i PC erano ancora molto costosi in proporzione al resto dei beni sul mercato ed io, nel corso del tempo, avevo messo a rischio stipendi interi dei miei genitori senza neppure saperlo.

Sostanzialmente avevo fatto di un sistema in produzione la mia personale sandbox, la mia scatola della sabbia con i giochi in cui sperimentare liberamente.

Un grave errore di valutazione il mio, senza però il quale, probabilmente, non avrei proseguito nella mia carriera informatica. Chi non risica, non rosica…

Gran parte dei programmatori che conosco si sono ritrovati nella mia stessa situazione, spesso fin dall’infanzia. L’unica differenza sta nella precocità con cui hanno avuto accesso all’informatica, quindi alle rispettive famiglie: chi ha (avuto) genitori che lavoravano nell’informatica, ha potuto sperimentare prima. Nel mio caso, pur avendo giocato con i PC fin dalle elementari a scuola, ho scelto l’informatica come “stile di vita” solamente quando ho potuto veramente esplorarla da solo, con tutti i guai del caso. Per questo, pur storcendo il naso quando penso alla FAT32 come filesystem “vecchiotto”, mi viene quasi da ringraziarlo, quale che sia una persona in carne ed ossa che mi ha fatto un grosso favore tanti e tanti anni fa.

Qui sta il punto: nell’epoca dei dispositivi iperpotenti, tanto da gestire virtual machine come bazzecole, perchè non insegnare l’informatica in modo “sandboxed”?

Un’umile proposta

Nel mio piccolo ho avuto anche qualche esperienza come insegnante di informatica, tanto per enti pubblici che per privati. Ebbene, lo confesso, non mi sono quasi mai attenuto ai libri o alle “linee guida” imposti dai miei committenti dei corsi perchè l’unico modo per insegnare l’informatica alle persone alle prime armi è liberarle dal rischio e farle sperimentare a piacere.

Un paio di lustri fa, rifiutai una proposta di regolarissimo lavoro part-time come insegnante di informatica di base presso una delle varie aziende di formazione del circondario. Concluso il “training” plurigiornaliero ed appena prima di firmare per “entrare in servizio”, optai per salutare tutti ed andarmene. Non era tanto il dover vestirmi in giacca e cravatta a darmi fastidio (beh, forse un po’ sì: avevo vent’anni!), quanto il dettarmi per filo e per segno cosa dovevo dire e cosa dovevo omettere. Lo scopo “fra le righe”, mai esplicitamente dichiarato, era ovviamente costringere le persone a ripetere il corso più in là. Per mia fortuna me ne accorsi in tempo e fuggii a gambe levate. Rispetto alle mie esperienze successive posso ora dire che quello fu di certo un caso isolato, come “modo di formare” le persone intendo. Nondimeno, ripensandoci di tanto in tanto, mi compiaccio di quella mia “fuga”.

Chi ha mai insegnato ad usare un PC a qualcuno – cosa ben diversa da “insegnare l’informatica di base“! – sa benissimo che il primo contatto con “la bestia elettronica” può essere micidiale. Anche l’essere umano che si sente un guru nel suo campo tende ad accusare il colpo, spesso in modo drammaturgico al limite del tragicomico:

“… come è possibile!? Ci riesce anche la zia Peppina e io no!?”

Qui si inserisce la mia banalissima proposta: perchè non un corso di informatica dentro una virtual machine? Una bella sandbox sicura in cui l’utente può sbagliare quanto gli pare e piace.

Perfino Wikipedia ha la sua bella pagina-sandbox in cui gli utenti possono sbizzarrirsi e provare in totale sicurezza.

Da Wikipedia: In informatica il termine macchina virtuale (VM) indica un software che crea un ambiente virtuale che emula il comportamento di una macchina fisica ed in cui alcune applicazioni possono essere eseguite come se interagissero con tale macchina. [...] Gli usi possibili sono: la simulazione di piattaforme hardware ancora in fase di progettazione (è questo uno degli usi originari) l’emulazione di un sistema operativo diverso da quello realmente installato sul proprio hardware al solo scopo di utilizzare applicazioni sviluppate solo per quello emulato e non per il proprio operazioni di “consolidamento”. Passare cioè da avere x server fisici per x servizi, all’avere un unico server fisico con x istanze del sistema operativo, ognuna delle quali istanze può eseguire uno o più servizi. Ebbene, io aggiungerei un quarto punto: “didattica sandboxed”

Potete sostituire le virtual machine con qualunque altro strumento che garantisca la certezza, reale o presunta, che si possa operare esattamente “come a casa”, potendo perfino distruggere tutto per imparare.

Uno degli aspetti più atroci per uno studente è la non ripetitibilità in solitaria delle nozioni acquisite. In altre parole: si sta attenti, ci si segna tutto per filo e per segno, ma arrivati a casa non si riesce a ripetere da soli quello che si è visto e fatto a lezione. Argh! Disperazione e rovina! Per evitare quella debacle didattica, un primo buon passo può essere il fornire gli stessi strumenti (metodo scientifico docet): l’adattamento o per meglio dire la capacità di uno studente di ripetere qualcosa in un contesto diverso (come può esserlo il PC di casa, diverso nell’HW e nel SO da quello usato a lezione) non è cosa immediata per tutti. Per questo una virtual machine “moderna” (ossia corredata da un’interfaccia grafica semplicata), usabile, clonabile, letteralmente trasportabile e (ri)usabile a casa rappresenta un buon strumento didattico. Come un libro che si usa a lezione e altrove. Di certo è meglio che costringere gli utenti a portare il loro PC “buono” da casa e rischiare di comprometterlo.

Libertà di sperimentazione è l’unico modo per entusiasmare le persone e quindi spingerle ad imparare con le loro stesse mani. Ripudio l’idea dell’insegnante come miserrimo enunciatore e verificatore di nozioni preconfezionate: preferisco l’idea (romantica?) di insegnante come catalizzatore, come casella “Via!” del Monopoli.

Dopotutto, se pensate ai vostri trascorsi scolastici, quali insegnanti ricordate in modo pienamente positivo? Per estensione, non avete forse ricordi spensierati e gioiosi di qualcuno che vi consentiva di provare qualcosa in assoluta libertà e neppure vi sgridava nel caso commetteste qualche errore? Quanto siete migliorati grazie a quei momenti?

Liberate il vostro utente, concedetegli di sbagliare e lui imparerà da solo. Fornite linee guida per non farsi male, non ordini da eseguire. Dategli una sandbox per farsi le ossa e lui vi ringrazierà.

Che ne pensate?

Zawinski’s Law of Software Envelopment

“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”

Una mia personale revisitazione generica di quella legge:

JP’s Law on Software Expansion

“Every software attempts to expand until it can even make coffee. Just before reaching that goal, someone else complains about that huge mess and will start a new tiny replacement project.”

Un buon software è spesso il frutto di un buon compromesso circa il numero di funzionalità incluse e “maneggiabili” da un utente medio.

Quello che molti sviluppatori non digeriscono proprio o fanno finta di ignorare è che l’utente medio si stanca in fretta di trovare sempre nuove funzionalità da imparare nelle sempre nuove versioni di programmi che utilizza: presto o tardi quel tipo di utente si ancorerà a vita ad una specifica release di un dato programma, rifiutando qualunque upgrade, oppure inizierà a cercare qualcosa di alternativo, che soddisfi tutte le sue necessità, ma senza farlo ammattire.

Capisco anche che il marketing spinga costantemente per poter disporre e vendere nuovi prodotti con nuove fantasmagoriche funzionalità, tuttavia questo non coincide necessariamente (o non coincide affatto) con il “Bene” del cliente.

Quante funzionalità può avere uno spreadsheet come Excel, quante ne conoscete e quante ne usate davvero? (Perfino voi cultori di questo genere di programma!)

Mi rendo conto che dare la colpa solamente al marketing sia un’ottima scusante, ma il problema è che noi stessi, gli sviluppatori, siamo i primi responsabili dell’espansione del software: se intravediamo la possibilità di aggiungere qualcosa ad un nostro progetto perchè ci piace o perchè sentiamo che ci serve, è molto probabile che l’aggiungeremo comunque, anche se non è fondamentale.

Arriviamo ad un punto essenziale: il bravo sviluppatore sa dire e sa dirsi no. Sa resistere cioè alle richieste che provengono dall’esterno per aggiungere questo e quest’altro (spesso non necessari se non “per fare numero” sulle brochure) ma sa soprattutto controllare il suo impeto creativo.

Non si tratta semplicemente di negare qualcosa ad un power user (ed uno sviluppatore lo è per definizione!) o un utente alle prime armi, si tratta di bilanciare un prodotto perchè sia usabile da entrambi e senza che nessuno dei due prenda il sopravvento come pubblico-target (a meno di software specifico, ovviamente).

Anzi, diciamocelo, se il software che viene progettato non è pensato per un uso iperspecialistico, dovendo scegliere, è meglio dire no al power user. Tanto quel tipo di utente ha sempre qualcosa di cui lamentarsi, ha sempre qualcosa di cui avverte la mancanza e che vi rinfaccerà alla prima occasione. Se poi è così bravo, magari modificherà o ricrereerà comunque da zero il vostro progetto, a suo uso e consumo. Per cui, perchè inseguire questo tipo di cliente difficile?

I power user – per quanto possa dar loro fastidio ribadirlo – sono numericamente poca cosa rispetto alla restante massa di utenti. Costituiscono certamente una minoranza forte e combattiva, è vero, ma non per questo devono averla sempre vinta.

Nel mondo FOSS è anche peggio…

Il mondo FOSS è una fucina di talento, un porto in cui le persone vanno e vengono, un ambito in cui il software non sta mai fermo. I progetti più importanti lo sono anche e soprattutto in virtù delle comunità che ruotano loro intorno; in ciascuna di esse si annida ogni genere di sviluppatore, da quello che spinge per fare il caffè istantaneo a quello che invece tende a frenare sistematicamente ogni novità.

Prima o poi, passo immancabile, tutti i progetti di successo si trovano alle strette fra “progressisti” e “conservatori” e l’esito di un tale scontro varia a seconda di molti fattori. Il vero problema, tuttavia, sono le frammentazioni del software a seguito di diverbi più o meno espliciti sull’evoluzione dei progetti FOSS.

Prendiamo un “caso storico”, il browser Epiphany:

Epiphany è la naturale evoluzione di Galeon (un progetto amministrato da Marco Pesenti Gritti) che aveva come obiettivo lo sviluppo di un programma che fungesse solo da browser. Il passaggio alla versione 2 delle librerie GTK+ ha portato molte novità (e incompatibilità), così si è optato per la riscrittura da zero del programma: Galeon è stato gradualmente inglobato in Epiphany.

Wikipedia inglese è più esplicita:

“Epiphany is an open source web browser for the GNOME desktop environment. The browser is a descendant of Galeon and was created after developer disagreements about Galeon’s growing complexity.”

Questo è solo un esempio di un vastissimo elenco. L’ultimo in ordine di tempo è il progetto Razor-Qt, l’ennesimo desktop environment, nato leggero, che sembra una reimplementazione di KDE 2/3.

Sul fronte GNOME, il fork di GNOME2, MATE, è invece un buon esempio di progetto nato come prosecuzione di qualcosa di dichiarato deprecato (GNOME2, appunto). Dal sito della distribuzione Mint, a sua volta una derivata di Ubuntu:

“MATE is a fork of Gnome 2 which is compatible with Gnome 3″

Non proseguirò oltre negli esempi. Mi soffermerò però sul punto che reputo essenziale: un software rimane vivo se viene seguito e migliorato costantemente.

“Migliorare” però non è solo “espandere”. Continuare ad aggiungere feature non è fare del bene nè al software (“più roba c’è, più roba si può rompere”) nè agli utenti (“più roba c’è, più gli utenti si romperanno di usarlo”).

Migliorare è prima di ogni altra cosa semplificare, agevolare l’utente medio, magari nascondendo ma non rimuovendo le funzionalità avanzate per i power user. In questo non mi piace nè l’approccio di KDE, zeppo di opzioni e parametri di configurazione anche per le quisquilie più superflue, nè quello di GNOME, troppo zelante nel levare tutto quello che – a sua detta – potrebbe confondere l’utente.

La virtù, al solito sta nel mezzo: un sistema semplice ma estendibile (es: tramite plugin) può far felici tutti i tipi di utenti. Si dà il minimo che l’utente medio può usare, ma anche ai rompisc… ehm… power user la possibilità di personalizzarsi e perfino riprogettarsi il software a loro uso e consumo, senza infastidire il resto del mondo.

Questo è un modo semplice per estendere il software senza renderlo eccessivamente carico fin dall’inizio e, possibilmente, senza spingere qualcuno a reinventarlo da capo.

La fluidità e l’impeto del variegato mondo FOSS sono indubbiamente la riprova che come modello funziona e funziona invero molto bene. Sono però convinto che la frammentazione di questo mondo – e relativa dispersione delle energie – sia una cosa estremamente negativa. Diciamolo, è un effetto collaterale estremamente spiacevole, spesso motivato da egoismo, rancore, pigrizia, … o da qualcos’altro, come la sindrome NIH. Come può sorgere qualcosa di positivo da un tale tipo di atteggiamento?

Che ne pensate! ^^

“Esiste una differenza sostanziale fra il modo con cui ci hanno copiato il ‘made in Italy’. Prendi i cinesi: loro ci copiano e basta, puntano all’imitazione e la qualità non è così importante. I giapponesi invece copiano per migliorare.”

Ora, questa frase ha almeno ventanni, nel senso che risale al periodo in cui mio papà lavorava per una celebre (allora) ditta italiana che produceva bambole, poi scomparsa più per smania di outsourcing che non per un qualche problema aziendale (così sostiene lui, conti e prodotti alla mano).

Sia chiaro: l’intento di questo post non è polemico nè tantomeno razzista (orrore!). Ho citato i nomi di due popolazioni, quella cinese e quella giapponese, ma in un contesto composto di stereotipi, ossia di presunti celebri “copiatori”. Un po’ come quando fanno con noi italiani, appioppandoci pizza e mandolino. Non è giusto, sono d’accordo, ma nascondere i nomi avrebbe reso il discorso un po’ troppo generico per i miei gusti.

In questo post non parlerò di outsourcing quanto vorrei riallacciarmi alla sopracitata frase, ossia al “modo di copiare“.

Sono certo che in essa vi sia una buona dose di risentimento verso chi “ha rubato il lavoro” ma, a sentire mio papà, era la qualità finale che proprio non gli andava giù: spostare la produzione ci può stare, ma darla in mano a qualcuno che fa il lavoro al posto tuo, ma lo fa male seppur a prezzi inferiori, è una situazione imbarazzante ed umiliante.

Imbarazzante per il buon nome della ditta che ci (ri)mette il marchio, umiliante per chi viene sostituito e non si capacita di esserlo stato per colpa di qualcuno che lavora peggio e che “costa meno“.

Cosa ho imparato

Io sono uno sviluppatore di software, non un ragioniere come mio papà, eppure non passa il tempo che non mi ritrovi in quelle parole. Non per gli stereotipi (anche se motivati dall’andamento dalla ditta dove lui ha lavorato), ma per il discorso fra le righe.

Il mercato lo fa chi investe, chi innova, chi si espone e rischia, chi ha un po’ di fortuna (o un surrogato). Il resto del mondo può provare a fare altrettanto, ma molto spesso si può accontentare di ispirarsi o “copiare” quel che può. Ossia imitare l’imitabile, possibilmente evitando di finire vittima di qualche battaglia sui brevetti, magari intentata da qualche “patent troll” di professione.

Un esempio di “reimplementazioni” (eufemismo) di prodotti esistenti è costituito dai cosiddetti cloni: In computing, a clone is a hardware or software system that is designed to mimic another system. Compatibility with the original system is usually the explicit purpose of cloning hardware or low-level software such as operating systems (e.g. AROS and MorphOS are intended to be compatible with AmigaOS). Application software can be cloned simply by providing similar functionality (all word processors have the same basic purpose), but may also be designed to support specific file formats (e.g., OpenOffice.org is intended to supplant Microsoft Office). Clones are created for various reasons, including competition, standardization, and availability across platforms.

Il passo dopo non è da tutti e separa chi copia e basta da chi vuole emrgere: copiare e migliorare, per mantenersi competitivi. Una specie di partita a guardie e ladri dove qualcuno ti copia ma poi si differenzia – e magari si salva pure dal punto di vista legale – apportando dei miglioramenti.

Condividere le conoscenze è una cosa estremamente positiva e spesso anche necessaria quando si lavora con altre persone o con altre aziende. Attenzione però a chi ed a come si forniscono informazioni. Da un articolo recente di The Register: Global arms and aerospace colossus BAE Systems this week released a high-profile audit into its internal ethics and served it up with a big slice of humble pie as it promised to be a better corporate citizen in future. But even as BAE sought to draw a veil over previous alleged indiscretions, it emerged that US officials have speculated that BAE, collaborating with US firms to build the supersonic, stealthed Joint Strike Fighter (JSF), could have allowed secret American military technology to move overseas, raising the possibility that the UK could benefit from expensive American research and development – even perhaps sell it around the world. [...]

Parlare di copie significa chiamare in causa “processi” più o meno legali: si va dalla copia spudorata, magari ottenuta rubando segreti industriale, al reverse engineering brutale o quello più o meno legale (es: clean room design).

Per un esempio di furto di segreti industrali e relativa copia spudorata vi consiglio l’eccellente libro “Sticky Fingers: Managing the Global Risk of Economic Espionage“: veramente un bel libro. Se vi affascina il mondo della “competitive intelligence” più spinta, ne trovate un breve spezzone nel bel film “The Corporation“, in cui parla un professionista di quel settore, Marc Barry. Se vi interessa infine un esempio cinematografico di “copia e miglioramento”, potete trovarlo nel film di fantascienza “Paycheck“, tratto da una storia di Dick, precisamente nel lavoro quotidiano del protagonista: “In the near future, Michael Jennings is a reverse engineer; he analyzes his clients’ competitors’ technology and recreates it, often adding improvements beyond the original specifications. [...]“

Restando nel mondo informatico …

Un esempio famoso è il progetto Hadoop:

“Apache Hadoop is a software framework that supports data-intensive distributed applications under a free license. It enables applications to work with thousands of nodes and petabytes of data. Hadoop was inspired by Google’s MapReduce and Google File System (GFS) papers.”

Un progetto che è nato come reimplementazione di un’idea e pian piano ha preso piede e supporto: l’elenco delle ditte che lo supportano è lungo. Di qualche giorno fa la notizia che anche Microsoft ha iniziato ad impiegarlo e permetterne l’uso nella sua piattaforma cloud, Azure. C’è addirittura chi dice che ormai sia meglio dell’originale da cui trae spunto.

Notate il trucco: rendere le “copie” OpenSource oppure parteciparne allo sviluppo sembra un buon modo per poter copiare, poi estendere/migliorare ed infine guadagnarci, spendendo il giusto e senza esporsi troppo a livello legale.

Chi dice che l’OpenSource fa male al capitalismo? (Sarcasmo)

Morale della fiaba

Con tutto ciò non sto invitando nessuno a copiare il lavoro di nessun altro, sia chiaro. Tuttavia, nel caso questa fosse la vostra scelta, vi invito a non fermarvi alla copia più o meno spudorata, ma a perfezionarla. Se proprio copia deve essere, almeno qualcosa di vostro e di nuovo, mettetecelo.

Rubare le idee di un altro è un atto ingiusto e reprensibile, ma buttarlo fuori dal mercato perchè una reimplementazione delle sue idee costa meno è pure un atto ignobile, di cui vergognarsi. A prescindere da quello che sostiene una certa teoria capitalistica.

Salire sulle spalle dei giganti per un giretto non previsto è un conto, approfittarne spudoratamente facendosi accompagnare ovunque (cioè una copia spudorata ripetuta sistematicamente nel tempo) è un’altra cosa.

Che ne pensate?

Ovviamente, penso non serva uno studio per capirne la portata, mettere in dubbio un acquisto può equivalere a mettere in discussione il raziocinio dell’acquirente.

Come se sbagliare un acquisto fosse una prova della stupidità di una persona…

Indagando sugli acquisti

Non sono uno psicologo nè il marketing è il mio campo, però non credo serva una terza laurea in queste discipline per osservare ed interpretare le reazioni delle persone intorno a noi quando si prova a discutere di acquisti.

Indipendentemente dallo spirito con cui si tratta l’argomento, critico-indagatore o neutro che sia, è facile osservare che l’acquirente di turno tende a mettersi sulla difensiva a priori, soprattutto quando gli acquisti non sono esattamente economici o appaiono insoliti rispetto alle sue scelte abituali.

Ovviamente mi metto nel novero, nel senso che in questo non sono diverso da nessuno: il marketing sa il fatto suo (cfr. bel post “Why We Buy: How to Avoid 10 Costly Cognitive Biases”).

Ad esempio, dovendo parlare di qualcosa appena comprato, si mette le mani avanti fin da subito con frasi come:

“Era in offerta!”,
“L’ho trovato in Rete a poco!” o
“Ho risparmiato un anno intero per togliermi questo sfizio!“

In alternativa lo si compara subito con qualcos’altro, magari ben più costoso e/o meno “potente”, in modo da salvarsi “per comparazione“.

C’è addirittura chi mente sul prezzo di acquisto, abbassandolo, pur di passare per un genio-dell’acquisto-ipescontato o per non farsi sbeffeggiare: salvo i ricchi io-compro-solo-cose-al-top-nei-negozi-al-top-e-mi-bullo-di-questo, il resto del mondo detesta spendere di più per lo stesso oggetto comprato dal vicino.

Tutta questa serie di trucchetti mentali, ho scoperto recentemente, rientra nella cosiddetta razionalizzazione post-aquisto (“Post-purchase rationalization”).

No, non è una malattia!

Da Wikipedia:

“Post-purchase rationalization is a cognitive bias whereby someone who purchases an expensive product or service overlooks any faults or defects in order to justify their purchase. It is a special case of choice-supportive bias.”

A sua volta, il pregiudizio a supporto delle scelte (choice-supportive bias) è così definito su Wikipedia:

“In cognitive science, choice-supportive bias is the tendency to retroactively ascribe positive attributes to an option one has selected. It is a cognitive bias.”

Sostanzialmente si medita seriamente sull’acquisto dopo averlo compiuto, cercando scuse per giustificarlo prima con sè stessi e poi, nel caso, a terzi. Penso sia chiaro che una spesa “insolita” urti prima noi stessi. Da Wikipedia:

“Cognitive dissonance is a discomfort caused by holding conflicting ideas simultaneously. The theory of cognitive dissonance proposes that people have a motivational drive to reduce dissonance. They do this by changing their attitudes, beliefs, and actions. Dissonance is also reduced by justifying, blaming, and denying. [...]

Experience can clash with expectations as, for example, with buyer’s remorse following the purchase of an expensive item. In a state of dissonance, people may feel surprise, dread, guilt, anger, or embarrassment. People are biased to think of their choices as correct, despite any contrary evidence. This bias gives dissonance theory its predictive power, shedding light on otherwise puzzling irrational and destructive behavior.”

Se poi nel frattempo dovessero emergere anche problemi, le “riflessioni interiori” aumentano. Come accettare lo smacco di qualcosa che, a caro prezzo, non ci soddisfa del tutto? Come accettare che il nostro costoso acquisto abbia dei difetti?

Gli esempi di sprecano: quello più comune è il vestito di un certo livello, magari più costoso del nostro “solito” vestito, che probabilmente indosseremo una sola volta o che “per magia” ci sta male appena varchiamo l’uscio del negozio.

Camerini con specchi dimagranti, le donne protestano Gran Bretagna palcoscenico di una singolare protesta: le donne inglesi infatti si sarebbero accorte (solo ora, vien da dire) che nei negozi di diverse catene di abbigliamento sono utilizzati strategici specchi dimagranti che traggono in inganno le clienti e le invogliano a comprare. [...] hanno scoperto che, in effetti, diverse note catene di abbigliamento usano il trucco dello specchio magico. Ma come hanno fatto a capirlo? Molto semplice: mettendo davanti allo specchio sospetto un CD, l’immagine riflessa era ovale.

Di esempi ne possiamo fare all’infinito. Quelli più tragicomici, probabilmente, sono quelli che riguardano i “fissati” delle varie marche: in quel caso l’elemento-brand amplifica ogni cosa.

I fanatici

Non vorrei dover citare nuovamente l’antenna-gate dell’iPhone 4, ma – viva la preterizione! – è troppo gustoso e recente come fatto che proprio non mi riesce di trattenermi.

Non mi interessa il fatto tecnico in sè. Quello che veramente mi ha tramortito – al limite del tipo di risata definita dall’acronimo LMAO – sono state le “arrampicate sugli specchi” di alcuni acquirenti per “giustificare” il bug, l’acquisto e quindi sè stessi. Curiosa questa sorta di “catena di responsabilità“: dall’oggetto costoso alla persona in carne ed ossa che l’ha comprato.

Ho sentito e letto di tutto. Da chi sparava ad alzo zero contro la concorrenza asiatica (se avete pensato qualcosa come “i soliti comunisti sud-coreani!”, la battuta è divertente ma geograficamente e politicamente errata), a chi minimizzava il problema dicendo di non averlo ancora incontrato o che si trattasse di una “leggenda urbana”, chi reagiva d’impeto con vari improperi verso gli intervistatori, eccetera.

Esattamente come i politici che cercano di dirottare le domande scomode sugli avversari: quando iniziano con “e voi allora, che…” o con “non accetto lezioni da …” sostanzialmente stanno ammettendo le colpe, ma non apertamente.

Il “consumatore” che diventa “difensore” di una marca specifica, penso rappresenti l’azimut del marketing per la marca stessa: più una persona diventa un “fan” dei prodotti di una qualche ditta, più “ci mette la faccia”, più ne prenderà a cuore la difesa.

The science of fanboyism

“We’ve all encountered them. They lurk in Internet message boards, comment threads, and chatrooms. Addressing anyone and everyone, they type up lengthy tirades with Cheeto-stained fingers, extolling the virtues of their product or brand of choice. They angrily accuse even the most impartial reviewers of taking handouts from reviled competitors of a beloved company, and they casually and systematically dismiss any evidence that might conflict with their worldview.

They’re known in our parlance as fanboys.”

Non è solo una questione di marche

Non vorrei passare per un saputello. Come ho detto, io stesso sono incline e vittima di questo meccanismo di razionalizzazione sugli acquisti. In realtà, credo, lo stesso discorso esuli da quell’aspetto commerciale, ossia interessi le scelte compiute.

Scegliere è in qualche modo esporsi. Tanto tempo fa, quando ho attraversato il mio momento da fissato del FOSS, mi ero spinto ben oltre quello che avrei voluto e dovuto fare: quando ci si fissa con qualcosa, si finisce ad eccedere nella sua difesa e, di riflesso, nella propria.

Curiosamente il FOSS non è un “brand” in senso stretto, ma è più una filosofia di vita, forse. Tuttavia molti dei suoi difensori lo fanno sembrare tale. Per non parlare dei veri “brand”, che lo usano come un elemento di marketing. Un po’ come la green economy: è una bella cosa, piace e suona bene, alleggerisce un poco la coscienza, fa presa sui “cuori” del pubblico – inclusi gli ambientalisti, incredibile! – e, cosa non da poco, è un marchio che in questo momento tira molto. In questi casi, dove è il limite fra il promuovere il rispetto dell’ambiente ed il marketing di un prodotto?

Schierarsi mette in moto qualcosa attorno a noi che va oltre noi stessi: in breve, mi ero costruito la nomea di “Pinguino”, un fatto che di per sè stesso non mi ha mai dato fastidio. Il problema è che quando qualcuno ti appioppa un’etichetta e tu non fai nulla per levartela di dosso (o, peggio, incoraggi chi hai davanti a farlo), finisce che ogni tua opinione, oggettiva o meno, viene interpretata come soggetta ad un ovvio pregiudizio di fondo. Un po’ come chiedere un parere politico a qualcuno che ha in tasca la tessera di un partito.

Di più: la gente di aspetta che tu risponda sempre allo stesso modo. Se nel tempo rivedi la tua posizione, ammorbidendola o stravolgendola, passi automaticamente nella categoria “voltagabbana” e perfino “ingrato”.

Sostanzialmente sto dicendo che se sei un “fanboy” di qualcosa o la gente attorno a te ti percepisce come tale, è facilissimo finire in una spirale sempre più stretta in cui, ad un tratto, ti accorgi che stai “svolgendo una parte” da cui è difficile uscire. La spirale può portarti a dire cose che non ti saresti mai sognato di dire e quindi, per non rimetterci la faccia, difendere ad oltranza l’indifendibile. Non è facile cambiare idea “pubblicamente”, perchè la cosa ha un impatto non indiffferente anche sul piano sociale.

Nel tempo, non ho paura di dirlo, ho ammorbidito molto la mia visione sul software commerciale. In parte perchè faccio parte di quel mondo – non sono ipocrita -, in parte perchè nel frattempo ho parlato con un bel po’ di persone e ho capito che “ammettere di aver ecceduto” non equivale a dichiararsi incapaci di intendere e di volere.

La stessa cosa negli acquisti: siccome ho imparato che nel prezzo di un bene concorrono alcune voci che non sono funzione della somma dei costi per realizzarlo e promuoverlo, non esito a condannare me stesso quando compro qualcosa di cui non ho davvero bisogno o per il quale potevo spendere di meno.

Credo che questo tentativo, per quanto di minima portata, sia un buon modo per cominciare a spezzare il vantaggio strategico del marketing su di me. Non funziona sempre, ma alcune piccole soddisfazioni me le sono tolte: di tanto in tanto il ricordo del rimorso dell’ultimo incauto acquisto razionalizzato mi spinge ad evitarne di nuovi con troppa facilità.

Non voglio sentirmi nuovamente a disagio per un acquisto di cui non posso essere soddisfatto al 100%.

Che ne pensate?

In questo post vorrei chiarire qualche punto che mi sta decisamente a cuore.

1. Cosa è una metodologia in soldoni?

Una metodologia è prima di tutto un modo rigoroso di fare le cose. Medesimo discorso parlando di filosofia o di modelli di sviluppo: cambiano i termini – spesso usati un po’ a casaccio, come fossero sinonimi perfetti -, ma il succo è quello.

Quando uno sviluppatore si ferma per un attimo e cerca di riassumere cosa ha imparato fin lì, quali sono gli aspetti migliori e ripetibili del suo lavoro, quali sono i passi che sistematicamente ripercorre, ecco che sta già riflettendo sul suo personale modo di operare. Di più: se riesce ad individuare un filo conduttore, un pattern comportamentale ricorrente, probabilmente sta già avvicinandosi alla sua personalissima metodologia.

Detto questo possiamo aprire il discorso anche alle numerosissime e più o meno rigorose nonchè famose metodologie di sviluppo (es: metodologie agili) che riempiono libri e paper a profusione.

O forse no: non importa quale metodologia uno segua. L’importante è che scelga quella più adatta a lui e, nel caso non esista già, crearla. L’importante è estrarre il modo di fare le cose per ripeterle in modo sistematico, senza forzarsi a farlo o perchè “qualcuno ha detto di fare così“.

Se ci si forza a fare le cose sempre allo stesso modo, anche quando non serve, si finisce poi a voler usare il proverbiale “martello” ovunque:

Law of the instrument (A. Maslow): “It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

2. Sceglierne una non equivale ad escludere le altre

Voglio qui ora affermare, in modo esplicito e diretto, un semplice concetto: non esiste una singola metodologia di sviluppo o un metodo/modello/filosofia/quello-che-vi-pare che vada bene a chiunque ed in tutti i contesti.

Questo fatto lapalissiano evidentemente tanto lapalissiano non è: viene spesso dimenticato con l’ovvia conseguenza delle continue guerre di religione fra i fautori di questa e quella metodologia che, al pari dei tifosi di una squadra di calcio, stravedono solo per la loro fazione, ed escludono le altre a priori.

In ambito informatico, voler essere troppo ortodossi nel rispettare alla lettera una qualche metodologia è come decidere di farsi dettare, punto per punto, il proprio lavoro: ho conosciuto persone che, trovatesi bene lavorando in un certo modo, lo impongono a loro stessi e a chiunque abbia la malaugurata idea di porsi loro di fronte.

Per questo genere di persona non esiste provare, sperimentare altro: trovata la loro scelta, quella è e quella rimarrà, almeno che non succeda qualcosa di grave (ma davvero grave), tale da costringerle al cambiamento. Una variazione estrema nonchè rischiosissima del celebre motto:

Squadra che vince non si cambia.

Mai farsi ingabbiare da un insieme di regole troppo stringenti, mai accettare un “lavaggio del cervello” metodologico in nome di qualche presunto e duraturo beneficio. Basta davvero poco per passare dall’ortodossia nel rispettare un metodo al puro fanatismo e quindi alle guerre di religione.

3. Non esiste una scelta assolutamente ottima

Non esiste una scelta ottima perchè i vari lavori, per quanto possano assomigliarsi, non sono mai esattamente uguali: il fatto che l’applicazione di un metodo in un certo contesto si sia rivelata una scelta azzeccata, non dovrebbe renderla l’Unica Opzione. Al massimo, dovrebbe renderla una delle opzioni favorite nel futuro.

Questo perchè nessuna metodologia, o metodo o filosofia è la migliore ed universalmente applicabile con successo: diffidate da chi vi promette la Luna se seguirete questa o quella metodologia. Nell’ambito della crittografia si parlerebbe di snake oil, con lo stesso medesimo significato: “prodotto truffaldino o fasullo“.

Analogamente non esiste – e probabilmente non esisterà mai – qualcosa in grado di aumentare automagicamente ed enormemente la produttività (qualunque cosa essa sia) o l’efficienza di un lavoro semplicemente applicandola.

No Silver Bullet (F. Brooks): “There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.”

Il solito esempio personale

La mia posizione, circa le varie metodologie di sviluppo più famose è di scetticismo a priori (cfr. recensione di un libro sulla metodologia agile Scrum).

Forse perchè è naturale aspettarsi che chi ti vende qualcosa – ad esempio un libro – tenda ad esaltare i vantaggi della materia trattata e a dimenticarsi degli aspetti negativi o a diminuirne l’importanza.

La mia strategia sulle varie metodologie col tempo è divenuta sincretica: fusione delle parti che reputo migliori, prese da ciascuna di esse. Nel caso di contrapposizione fra concetti – capita spesso che due metodologie si scontrino più o meno apertamente su determinati aspetti -, compio una scelta esclusiva.

Ad esempio mi piacciono singoli aspetti di Scrum, dell’Extreme Programming, del Tracer-Bullet Development, eccetera. Tuttavia rifiuto di adottarne una – ed una soltanto – in nome della flessibilità di impiego nell’assemblarne una mia.

In “Lord of War“, uno dei miei film preferiti, ad un tratto comprare questa bellissima frase: “Ogni fazione in Africa si attribuisce questi nobili nomi: Libertà, Patriottismo, Repubblica Democratica. Credo che loro non ammetterebbero mai quello che sono in realtà, i peggiori oppressori degli ultimi oppressori. Spesso le maggiori atrocità avvengono quando entrambe le parti in lotta si proclamano combattenti per la libertà.” Credo che lo stesso tipo di ragionamento si possa applicare anche ad un discreto numero di metodologie “mainstream”: molte di esse parlano apertamente di flessibilità d’uso, di rifiuto dei fanatismi, di “libertà” del programmatore, eccetera. Salvo poi indicarti – ooops! – schemi ultraprecisi da seguire e a prova di “eretico”, “consigli” più o meno velati sui libri da comprare, training “ufficiali” da frequentare (ovviamente tutti a caro prezzo), certificazioni da ottenere, eccetera, eccetera. Non di rado da una metodologia si dipartono poi nel tempo varie “scuole di pensiero”, ognuna con i suoi pseudo-dogmi, i suoi pseudo-guru di riferimento, spesso “discepoli” del o dei “fondatori”. Non di rado, infine, si aprono “guerre di religione” fra gli “adepti” delle varie metodologie.

Il pair programming, ad esempio, sulla carta è un modo di scrivere e debuggare il codice molto interessante e probabilmente anche utile.

Tuttavia, salvo rari casi (mentoring?), è difficile pensare di adottarlo in pianta stabile, tantomeno dimostrarne in modo incontrovertibile l’efficienza/efficacia: sembra di sentire quella barzelletta sui carabinieri, che fanno sempre le cose in due ed uno si limita ad osservare o supervisionare.

Bear programming (B. W. Kernighan e R. Pike): “Another effective technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed “Never mind, I see what’s wrong. Sorry to bother you.” This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor.”

Credo che il punto principale sia proprio quello: è fondamentale imparare quanto più possibile di tutto, per scegliere al momento opportuno quale strada percorrere, ma fra più opzioni, non una sola. Il trucco sta nell’infischiarsene bellamente se su un dato libro di un certo autore su una data metodologia viene detto che, se non la si segue tutta ed in modo rigoroso, accadranno le “peggio cose“.

La mia personale strategia, alla base del mio sopra-citato “sincretismo metodologico”, è quello che gli anglofoni definiscono cherry-picking, ossia prendere qui e là le idee che reputo migliori e confezionare qualcosa di nuovo. Mi sono perfino capitati diversi casi in cui ho adottato una certa strategia o metodologia per poi ritrovarmi ad usarne una “opposta” in un altro progetto.

Questo vale anche per le coding convention. Esempio classico, “metodologico” per come opero io: detesto lo stile di indentazione K&R e nei progetti che seguo io, se posso, lo evito. Ma dovendo estendere del codice altrui già esistente e/o dovendo scrivere del codice in un linguaggio in cui è la norma, allora me ne faccio una ragione perchè reputo la consistenza del codice più importante dell’aspetto esteriore o dei miei gusti. Questa regolina fa parte della la mia personalissima “scala dei valori” nonchè del mio modo di fare.

Detto questo, possiamo aprire il discorso sogni.

Skunkworks

Ogni sviluppatore presto o tardi si “invaghisce” professionalmente di qualcosa o di qualcuno, diventandone una sorta di “fan”. Il mio modello/non-modello preferito nonchè sogno-ultimo-definitivo si chiama Skunk Works:

Skunk Works is an official trademark for the Lockheed Martin Advanced Development Programs (formerly Lockheed Advanced Development Projects).

The designation “skunk works”, or “skunkworks”, is widely used in business, engineering, and technical fields to describe a group within an organization given a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects.

Perchè? Semplice: chiunque sia stato in grado di produrre l’SR71 “Blackbird”, il mio aereo militare preferito fin da quando ero bambino (nonchè base dell’aereo degli X-Men), sa il fatto suo. E i tizi in questione hanno progettato gran parte degli aerei militari più “spettacolari” in circolazione, per cui conoscono davvero bene il loro mestiere.

Sia chiaro: non sono mai stato un “guerrafondaio” e nemmeno un amante delle armi. Tuttavia, da tecnico, non posso non rimanere affascinato dai continui e ben foraggiati progressi della tecnologia bellica. Non a caso il “Blackbird” non era un caccia ma un ricognitore strategico statunitense, capace di una velocità di Mach 3+.

Anzi, sono così bravi nel loro ambito che ormai il nome del loro dipartimento è diventato l’emblema del loro modo di lavorare e viceversa:

“A skunkworks project is one typically developed by a small and loosely structured group of people who research and develop a project primarily for the sake of radical innovation. [...]

A skunkworks project often operates with a high degree of autonomy and unhampered by bureaucracy, tasked with working on advanced or secret projects. These projects are often undertaken in secret with the understanding that if the development is successful then the product will be designed later according to the usual process.”

Innovazione radicale al limite del dovere alla segretezza, autonomia e poca burocrazia: credo sia il sogno di qualunque sviluppatore. Lo è anche il diventare un simbolo di efficienza, ovviamente.

Come dite? Non è un modello ma una filosofia o un contesto operativo o una metodologia? Beh, a dispetto della scelta della terminologia che si può impiegare per definirlo, “skunkworks” continua ad essere il mio punto di riferimento “onirico” ad alto livello, su cui poi innestare tutto il resto.

Che ne pensate?