L’assenza di progettazione non è Lean

Uno dei tenet di una certa interpretazione della metodologia Lean è che sia possibile “partire leggeri”, senza grandi investimenti in progettazione, e che in particolare, il design di prodotti sia alla portata veramente di chiunque, in particolare per artisti e per “practictioners” armati di pennarelli colorati e modellini di cartoncino. Questo modo di procedere, spinto agli estremi, porta a dubitare che per le Startup si applichino le leggi della fisica, non parliamo di principi assodati di Ingegneria del Software, che suonano sempre meno “politically correct” man mano che il tempo passa.

Dico una certa interpretazione della metodologia Lean, perché secondo la mia personale comprensione di “Running Lean” di Eric Ries, un MVP, minimum viable product, è il minimo insieme di caratteristiche funzionali che un potenziale utente è disposto a pagare, ed è il primo prodotto che dobbiamo preoccuparci di produrre. Ma deve essere un prodotto, vero, nel concreto e tangibile senso del termine!

Quindi se cercate di spacciare un prototipo costruito in cartoncino per un prodotto funzionante, o una serie di immagini realizzate con un editor grafico ad un prodotto, potete al massimo verificare se c’è un po’ di interesse per un possibile prodotto. Però secondo la mia personale interpretazione, il prodotto deve esistere, e deve fisicamente svolgere le funzioni che dichiara di svolgere.

È inutile sposare una metodologia e volerla seguire separandola dalla competenza necessaria per applicarla concretamente alla disciplina in cui si sceglie di operare: Si rischia di finire ad occuparsi di Cargo Cult methodologies, in cui il seguire rigorosamente tutti i cerimoniali ed i riti previsti, inspiegabilmente per il praticante della metodologia slegata dalle necessarie conoscenze teoriche e pratiche, non conduce alla costruzione di oggetti funzionanti.

È impossibile realizzare un prodotto “in un secondo tempo”, se l’idea fisica su cui si fonda il progetto non è stata dimostrata, se non con un prototipo, perlomeno con dei calcoli di fattibilità ed utilizzando un insieme di conoscenze scientifiche e tecnologiche.
Altrimenti la progettazione si trasforma nel “disegna l’astronave” sul quaderno da disegno dei bambini. Non è possibile pensare di poter produrre un apparecchio elettronico ne’ tantomeno “progettarlo” senza sporcarsi le mani, per l’appunto, con l’elettronica!  Si finisce per dare una immagine stranamente falsa, contraddittoria, irreale, che fa venire dei dubbi a persone abituate a ragionare, o che magari conoscono un minimo l’argomento di cui si parla.

Di qui la mia diffidenza per tutti i practictioners di Design Thinking e di Lean Methodologies che non hanno mai realizzato un software (non sanno nemmeno da che parte si inizia), non hanno mai visto l’interno di uno studio di progettazione e mai hanno partecipato alla creazione di un prodotto industriale. È possibile che il vedere la progettazione come qualcosa di semplice, che si può fare solo “disegnando delle forme” sia uno dei tanti casi di sindrome di Dunning/Kruger : quello che non si conosce viene erroneamente definito “semplice” e ci si sente a proprio agio nel dichiararsi esperti di cose che non si conoscono.

È ben per questo che il definire “facile” l’attività di scrittura del software è profondamente diseducativo. Fatto bene è un lavoro duro, che richiede impegno, e l’esperienza consiste soprattutto nel non commettere errori già visti, già sperimentati.

Se tutto quello che avete alla fine della vostra attività di progettazione è un modellino di carta, non avete in mano alcunché, nemmeno la possibilità di ricavare dei dati e delle ulteriori informazioni da parte dei vostri clienti, dato che misurare la risposta ed il comportamento dell’utente di fronte ad un modello di cartone è una impresa disperata. Un modello di cartone non costruisce uno skillset, non in elettronica ne’ in informatica, non vi consente di imparare.

Certo potete improvvisare dei giochi di ruolo in cui scambiate delle carte davanti a degli “utenti” che fanno parte del vostro team, ma questi modellini di cartono non possono certo venire definiti prototipi funzionanti.
Il confondere la forma con il prototipo è una distorsione percettiva che, secondo me, può venire dagli architetti: per loro la forma può davvero essere l’oggetto da realizzare, quindi costruire un modellino in scala (calcoli strutturali a parte) può in un certo senso venire considerato un “prototipo”.

Gli Architetti (e per architetti intendo in questo caso con precisione proprio i progettisti di “spazi a misura d’uomo”, e non i progettisti di sistemi informatici) sono in genere fondatori di movimenti culturali che spesso hanno ampia risonanza nella progettazione del software, anche più che nella loro disciplina originale, ma questo non è uno di quei casi. Concetti come “decomposizione funzionale”, o “form follows function” e “pattern” li hanno inventati proprio gli Architetti!

Ma certamente non basta un modellino di cartone quale prototipo se volete costruire una lavastoviglie o una radio. Costruire un prototipo di una lavastoviglie, a parte l’aspetto puramente estetico, richiede un lavoro più complesso, ed anche misure sul campo.

Altrimenti, come fare per far si che una lavastoviglie possa definirsi “a basso consumo”? Occorrono approcci progettuali precisi, calcoli, e non semplici fattori estetici.

Allo stesso modo, un mockup con dei disegni di schermate, non è da solo un “progetto software implementabile” (con buona pace di molte agenzie di comunicazione/pubblicitarie/web e simili).

A volte armati solo di una metodologia di analisi dei bisogni e delle percezioni degli utenti, ci si avventura addirittura a produrre immagini patinate e design dalla linea filante di prodotti innovativi.

Tanto basta creare una presentazione su Kickstarter o Indiegogo, con un video convincente, e limitarsi a fare attività di progettazione ed ingegneria come afterthought, in fondo la tecnologia dei renderer fotorealistici consente di far correre dei dinosauri, volete che non sia in grado di fornirvi la foto di un prodotto che non esiste?

Il problema nasce quando “prodotti” che finiscono per racimolare premi di design (ma chi fa parte di certe commissioni?) si scopre sono fisicamente irrealizzabili così come descritto dai “progettisti”.

Ed è il triste caso di Fontus, un capolavoro di design di una bottiglia che si riempie da sola, e che sarebbe bellissima, se solo fosse possibile costruirla e produrla come descritto nella sua campagna di lancio.

Purtroppo Fontus non è realizzabile, stanti le attuali conoscenze di termodinamica e sulle celle fotoelettriche. Poeticissima l’idea di una bottiglia per ciclisti che si riempie da sola, sicuramente se esistesse e fosse possibile, senza portarsi dietro svariati metri quadri di pannelli solari, ci sarebbe un mercato. Però ci sarebbe un enorme mercato anche per lampade di Aladino, tappeti volanti, teletrasporto e bacchette magiche: desiderare che qualcosa esista non lo rende ne’ reale ne’ realizzabile.

Questo è un certo tipo di design dell’era moderna, di gente abituata a vincere facile, convinti che sia sufficiente eliminare i lati difficili, che tanto sono negativi e non interessano nessuno, forse basta trovare un Ingegnere in un secondo momento, o coinvolgere uno sviluppatore purché pagato poco 🙂

Anzi, fare progettazione “lentamente”, misurando i passi, e calcolando quello che si fa è una moda così sorpassata, una cosa “da vecchi”. A voler considerare le cose da un certo punto di vista, è sempre l’eterna dicotomia tra forma e sostanza. Con la forma ci si può far notare, ma armati solo una ottima forma, in genere non si costruiscono grandi risultati industriali.

Rattrista essere a conoscenza di gente che dichiara di volersi occupare di “progetti finanziati di ricerca”, per esempio in elettronica, e che millanta di occuparsi di Grafene, ma che palesemente non dispone di alcuno strumento di misura elettronica, nemmeno un misero multimetro digitale.
Che vogliamo fare, l’elettronica su quaderni a quadretti nel 2017?

Nota bene, reputo che la gioia giocosa sia essenziale nel produrre nuove idee creative, ma non è possibile “farsi degli sconti” e non svolgere anche tutto il resto del percorso, quando ci si occupa di progettazione.

Musica a 432 Hertz

A 432 Hz suona meglio… oppure no?

Oggi voglio parlare dei numerosi articoli che vengono pubblicati sulle proprietà mistiche delle vibrazioni, e sul fatto che una corretta accordatura a 432 Hz per il LA centrale migliori la possibilità per la musica di “risuonare naturalmente”, con effetti benefici sull’umore e via discorrendo.

Purtroppo la musica è fortemente legata alla matematica, e su alcune cose non si può barare.
Le frequenze delle note basate sulla scala temperata sono facilmente calcolabili.

Si procede così:

Data la frequenza di una nota, il semitono successivo si ottiene moltiplicando quella frequenza per radice dodicesima di due. Infatti la frequenza deve raddoppiare passando alla stessa nota per l’ottava successiva. La frequenza di riferimento è da secoli il LA centrale della tastiera del pianoforte.
E’ la nota che corrisponde alla lettera A nella notazione Anglosassone,

Questa frequenza è la stessa del segnale di occupato usato in telefonia, o del segnale del monoscopio in televisione.

Dato che su una scala temperata le note distano ciascuna rispetto all’altra per radice dodicesima di due, e che il La centrale è a 440Hz, la frequenza di 432 Hz non è presente in alcuna nota emessa da uno strumento intonato.

Infatti dividendo per radice docidecisima di due 440 otteniamo:

f (la) = 440 Hz

f(la b) = 440 / 1.05946409 = 415 Hz, frequenza del La bemolle centrale = Mi#

Quindi ne’ il Mi diesis (semitono precedente) ne’ il La centrale hanno come valore 432.

La frequenza di 432 Hz è vicina al La centrale, ma non abbastanza.

Storicamente si sono usati come valori del LA 442 e 443 Hz, ancora più lontani… e per cui comunque non si ottengono comunque valori vicini a 432 Hz, mai.

Dubito che un direttore d’orchestra possa decidere di accordare in basso di quasi due cent, aspetto smentite.

Sul risuonare a 432 Hz, attendo che qualcuno possa trovare dei valori di frequenza corrispondenti a note presenti sulla scala temperata, ed il cui multiplo faccia 432, lo dico in senso ironico…

Perché a 432 “risuoni” alcunché, il valore 432 dovrebbe corrispondere esattamente ad un multiplo intero del valore di almeno una frequenza di una nota di ottave precedenti quella centrale.

Ma così non è:

Se dividiamo per due ci troviamo a 216 (e la frequenza del La si è spostata a 220 Hz).

Qualsiasi divisione per potenza di due non ci porta a valori che coincidano con note appartenenti a scala temperata correttamente accordata.

Se dividiamo per tre ci troviamo a 144 Hz. Sfortuna… le note più prossime valgono 139 e 147 Hz.

Se dividiamo per cinque otteniamo 432/5=86,4 Hz. Note più vicine a 83 ed 88Hz…

Una ipotetica sesta armonica: 432/6=72 Hz. Anche qui, le frequenze più vicine di note correttamente intonate sono 70 e 74 Hz  (e NESSUN MUSICISTA che non sia sordo come una campana/incapace accorda il proprio strumento in modo che emetta ESATTAMENTE una nota intermedia tra un Do diesis ed un Re …).

A 432 non risuona alcunché che sia collegato ad una scala temperata, e, come abbiamo visto, eventuali sovrapposizioni con la frequenza di 440 Hz sono imputabili ad errori di accordatura…

Questa dei 432 Hz è una sonora stupidaggine, ed è divertente in quanti abbocchino a fandonie come questa, semplice fuffa basata sul nulla e su affermazioni prive di merito e facilissime da confutare, numeri alla mano.

Circolano anche voci fantasiose e, per quello che mi risulta, antistoriche: i 440Hz sarebbero carichi “negativamente” perché l’intonazione a 440Hz sarebbe stata decisa, nientepocodimenoché da Goebbels, mentre i Pink Floyd avrebbero suonato con l’intonazione a 432Hz, per “migliorare la qualità del suono”.

La prima affermazione è falsa, si è arrivati alla intonazione a 440Hz attraverso un comitato internazionale, e per un fine nobile: consentire a tutti gli strumentisti di poter suonare insieme senza problemi, uno dei tanti casi di COOPERAZIONE internazionale, altro che negatività, ed il nazismo non c’entra minimamente, si tratta di uno standard approvato negli anni 50!

La seconda è altrettanto falsa: i Pink Floyd avevano come ingegnere del suono un tizio chiamato Alan Parsons, che è ben noto a chiunque si occupi di audio a livello professionale, o anche solo a livello poco più che amatoriale. Il signore in questione ha rilasciato al pubblico i suoi appunti, consultabili online, in cui, se per caso spostando verso il basso di 8 Hz l’accordatura del LA si fossero ottenuti dei vantaggi, ci sarebbero delle tracce nei suoi scritti e sarebbe stranoto a chiunque si occupi di ingegneria del suono.
Ovviamente non è così. Nei forum di ingegneria del suono si parla della teoria dei 432Hz, in modo umoristico, e viene considerata unanimemente una sonora bufala, allo stesso livello delle teorie dei rettiliani.

Parliamo di Innovazione

Innovare, dal latino “novus”, significa introdurre delle innovazioni.
Può essere di due tipi:

  • Introduzione di novità non precedentemente presenti ed aventi carattere di originalità.
  • Imitazione di novità non presenti nel proprio mercato/settore.
    Nel primo caso si parla propriamente di invenzione, nel secondo  caso di adozione o di diffusione (a seconda del ruolo esercitato nel proprio mercato).Il ciclo di vita di un prodotto, ma anche di una idea o di un concetto, è caratterizzato dalla sua adozione in fasce temporali successive, da parte di utilizzatori progressivamente sempre meno “innovatori”, a seconda della propensione al rischio, intelligenza, adattabilità plastica a nuove idee:
  • inception: viene adottato da innovatori radicali, detti early-adopters
  • chasm between early adopters and mainstream. E’ la zona di “bonaccia” ed assenza di vendite in cui di solito naufragano o stentano le nuove idee ed i nuovi prodotti, dopo le prime avvisaglie di possibile successo (dovute agli early adopters).
  • mainstream: viene adottato dal grande pubblico di late adopters: utenti senza non amanti del rischio, che in buona sostanza segue delle mode e ripete quello che vede fare agli altri. Se si tratta di un prodotto o di un servizio, questo diventa una “cash cow” e genera grandi qualità di danaro. Chi lo ha introdotto sul mercato rischia il pericolo di diventare compiacente, e di ignorare minacce nascenti da parte di competitor maggiormente innovativi. Le aziende veramente innovative tendono a rendere obsoleti i propri prodotti prima che lo facciano altri, sostituendoli autonomamente.
  • obsolescence: il modello proposto viene alla fine adottato anche da laggards, utenti che resistono attivamente l’innovazione ed acquistano qualcosa solo dopo che lo hanno fatto proprio tutti, in genere sposano un modello quando è praticamente già obsoleto ed esistono alternative più valide che iniziano a diventare mainstream, oppure rimangono fedeli alla propria scelta iniziale, compiuta anni ed anni prima. Hanno ancora minore propensione al rischio del pubblico mainstream. Oggi un laggard è per esempio chi in azienda utilizza ancora versioni obsolete di Explorer, con cui chiede la compatibilità, oppure chi pensa di utilizzare Bootstrap per un sito web che vuole definire innovativo e dedicato al grande pubblico, perché così fan tutti, e quindi non si può sbagliare.A voler fare la chiosa sulle intenzioni, viene da interpretare maliziosamente frasi del tipo “l’innovazione non è invenzione” con il maldestro tentativo di un late adopter di spacciarsi per innovatore a tutti i costi.
    Altri esempi nella vita (informatica) di tutti i giorni:Scelta di Java all’interno di un sistema informatico sviluppato dal nuovo, e giustificazione sulla base del: “le risorse umane costano poco”, “non si può sbagliare” o simili…Gente che si definisce “innovatore”, ma la cui principale innovazione tecnica consiste nel passare da Java Swing (circa 2010) a Java EE. e nel 2017.Ho conosciuto persone che si vantano di essere stati “il primo programmatore in Italia di Java” e che ad oggi, in “startup innovative di cui sono direttori tecnici” che propongono Java e PHP. Java sembra essere diventato il nuovo Cobol.E’ anche vero che se tutto quello che conosci come strumento è un martello, è difficile che il resto del mondo non venga visto come chiodi.

    Mi è stato chiesto di recente perché abbia utilizzato Golang per scrivere delle architetture back end.
    La cosa divertente è che chi me lo ha chiesto si è risposto da solo, “per passione”, non prendendo nemmeno in considerazione che questa strana scelta stravagante possa aver funzionato bene, o portato a casa un qualche risultato economico rilevante (tipo l’essere riuscito a raggiungere un certo risultato con mezzi economici veramente scarsi, in tempi rapidi e con buon successo prestazionale).

    A questo scopo è interessante notare la presenza di modelli e matrici per valutare la competenza di uno sviluppatore che sono semplicemente sconosciuti, lettera morta in Italia, tipo questa:

    Il problema è che da noi purtroppo viene spesso da dubitare che ci occupiamo davvero di informatica, da paese civile ed industrializzato.
    Troppo spesso chi seleziona cerca solo una conferma dei propri pregiudizi, visione del mondo, che spesso sono o semplici miti, o proiezioni e ricerche di autoconferme. E le decisioni sono spesso prese per sentito dire, senza nessuna riflessione critica, nessun esperimento. E dire che l’informatica nasce come disciplina scientifica, come ramo di matematica applicata, poi, purtroppo, sono arrivati gli ingegneri, ed in particolare gli ingegneri italiani.

    Esempi di miti:

    I più giovani sono innovatori: Falso, essere un innovatore è un attributo personale, e sono innovatori radicali ed early adopters pochissime persone. È difficile che un innovatore non sia un early adopter anche in altri campi, se manifesta posizioni “conservative” troppo spesso, sarà ben difficile che non effettui scelte conservatrici anche quanto a progetti.
    E il caso in cui si cerca, con approccio cerchiobottista, di prendere due piccioni con una fava: essere innovativi (a parole) ma senza voler davvero rischiare.
    Es.: medio dirigente di aziende non particolarmente innovative fonda startup, in cui prosegue sostanzialmente con continuità rispetto alla mansione precedente una “azienda innovativa” in cui continua a fare esattamente quello che faceva presso il suo primo datore di lavoro, sostanzialmente con gli stessi strumenti, informatici e concettuali. Vi aspettate delle innovazioni radicali?
    Siete degli ingenui ottimisti, e, cari investitori, otterrete un prevedibile ritorno sull’investimento di una normale piccola azienda di nicchia. Se per caso avete successo, dovrete buttare via e ricominciare tutto daccapo.

    Una persona competente conosce bene il linguaggio di programmazione che mi serve: Falso, una persona competente ragiona a livello concettuale e mappa il problema sul linguaggio e sulla soluzione più valida, il linguaggio ed il framework non è necessariamente l’unico elemento importante.
    Conoscenza è sapere, skill è sapere fare. Skill senza conoscenza vale esattamente zero, tanto quanto la conoscenza puramente teorica .
    Un buon praticante riflette sulla teoria e la applica praticamente, spesso producendo risultati propri.

    In questo senso vale più una conoscenza come “cultura generale” dell’esistenza del concetto di pattern software, unita ad esperienza di vita concreta, che non il pedestre tentativo di memorizzazione dei pattern ed il gioco ad “infila quanti più pattern puoi nel tuo progetto”. L’apprendimento puramente mnemonico, se devo dire la mia, in genere identifica i soggetti meno capaci: gente che conosce un linguaggio perfettamente, ha studiato, ma all’atto pratico non è in grado di scrivere dei programmi in modo originale, ed a volte non è nemmeno in grado di effettuare una banale decomposizione funzionale in modo autonomo.

    Fissarsi sulla conoscenza mnemmonica di linguaggi e piattaforme toglie poi letteralmente ossigeno alla possibilità che vengano sviluppate soluzioni davvero innovative in modo disruptive, per pochezza culturale e concettuale, l’uso di strutture dati complesse e di algoritmi sofisticati non viene mai preso in considerazione, nemmeno quando potrebbe portare concretissimi e decisamente netti vantaggi in termini di efficienza, produttività, prestazioni.

    Anzi, in un ambiente retrogrado, il “pensatore originale” viene di solito accusato di essere “poco concreto”, dimenticandosi che l’intera industria informatica è una costruzione concettuale, costruita letteralmente su astrazioni e livelli di astrazione.

    Conoscere bene le strutture dati e la teoria è più importante che non avere la padronanza di un particolare framework o linguaggio di programmazione (ed anzi, se conosci un unico linguaggio di programmazione in genere questo la dice lunga sul tuo personale ruolo di late adopter e motivazioni: ti sei fossilizzato presto, nel corso della tua carriera).

    Il problema delle piccole aziende in genere è il successo, non appena arriva, si passa rapidamente all’autocompiacimento, e ci si costruisce una visione del mondo in cui il capo decide, ed i sottoposti eseguono. Si chiede formalmente “di pensare ed essere propositivi”, ma qualsiasi proposta viene rapidamente scartata. La ricerca dell’efficienza a tutti i costi conduce paradossalmente proprio a questo: best practices e controllo strettissimo su processi, competenze (quelle “giuste”, già decise, ed architetture e soluzioni scolpite nel granito). Il risultato è nessuna flessibilità e zero tempo per fare qualsiasi esperimento che contraddica la visione del mondo di chi dirige e che è l’unico ad avere la delega di pensare in modo autonomo.
    Risultato: le best practices spinte all’eccesso spengono qualsiasi innovazione.
    Si fa tutto perfettamente, ma il mondo cambia, e si rimane fermi sulla propria posizione.

    Vuoi innovazione? Ci vuole Slack!
    Nonaka e Takeuchi, due ricercatori giapponesi che hanno fondato la disciplina del knowledge management affermano che per innovare occorre avere tempo a disposizione “slack”, in cui sia possibile “esplorare”.
    Ricordo come esempi di eccellenza la Google iniziale, con il 20% del tempo lavorativo a disposizione per progetti “propri” dei dipendenti, a volte sfociati in nuovi prodotti di Google (e poi istituzionalizzata con la creazione di Alphabet, o la HP dei tempi in cui era ancora una delle prime aziende di ingegneria e strumentazione del mondo, in cui il laboratorio e gli strumenti erano in modo molto innovativo “aperti” e disponibili.

    Volete riconoscere una azienda morta dentro?: è passata ad ISO9000, ma senza una vera cultura della qualità, e si concentra su formalizzazione dei processi in stile ITIL. L’idea di base,  è che le persone non siano importanti, e tutte le scelte mirano non a trovare una soluzione migliore, ma una in cui minimizzare l’importanza del fattore umano, con l’idea che i progettisti debbano in qualche modo essere ingranaggi, facilmente sostituibili.  Le procedure e la documentazione servono, ma non nascono con l’intento di reprimere qualsiasi innovazione. Il processo è un mezzo per lavorare meglio, ma non certo un fine da perseguire, altrimenti diventa solo un rituale, privo di significato, se non completamente deleterio.

    Il risultato di una efficienza rigidamente eseguita sulla base di best practices, con compiti assegnati e tempistiche inflessibili, strettamente monitorate, è che si producono sistemi non scalabili, non aggiornati, si ignorano le possibilità offerte da nuovi approcci, e si buttano via fiumi di soldi e di opportunità, naturalmente credendo di risparmiare e sicuri di fare tutto benissimo. Infatti chi è costretto a lavorare sulla base di task con tempo di soluzione assegnato per la soluzione di problemi piccoli e ripetitivi, perché mai dovrebbe “rischiare” ed esplorare nuove soluzioni? Non ne ha il tempo, e se lo facesse verrebbe escluso dal sistema.

    Purtroppo poi molte best practices sono semplici mode, diffuse da gruppi e società come brand per servizi di consulenza che non necessariamente sono allineate con gli obiettivi dei propri clienti, ma che hanno come unico fine l’aumento delle billable hours (le ore fatturatili impiegate in un progetto).
    Le grandi aziende di consulenza sono gli ultimi a fare da innovatori: devono accontentare clienti retrogradi, che le scelgono proprio perché sono dei conservatori. Per loro fare innovazione significa catturare delle parole chiave e cercare di inserirle nella propria organizzazione, ma spesso seguendo idee, ricette ed uomini secondo vecchi rituali. Si riuscirà ad essere conservatori anche nel perseguire progetti su Intelligenza Artificiale, Big Data e block chain? Si accettano scommesse, anche se sarà difficile superare autoinganno ed autocelebrazione.

    Alcune idee apparentemente sensate, quanto ad architetture informatiche, in realtà sono pessime: l’approccio a componenti software per UI in Java (un po’ come il socialismo reale, idea bellissima ed utopica, che però attuata produce grande sofferenza). Provate ad usare JSF, ed un normale MVC scelto a caso, notate delle differenze?

    Altre sono idee che sembrano buone sulla carta, ma non sono basate su riflessione e prova concreta sperimentale (che altrimenti ucciderebbe rapidamente questi approcci). Per esempio tra queste l’idea di utilizzare degli ORM per la persistenza dei dati, spesso sostituendo a gestione di codice dei complicati file XML di analoga o superiore complessità, nel disperato tentativo di riconciliare logica object oriented (java) con database intrinsecamente tabulari e basati su linguaggi dichiarativi di tipo SQL, tra l’altro così facendo infilando nello scarico del lavandino tutto il patrimonio di pratiche e conoscenze sul trattamento delle basi dati, con principi di integrità referenziale che rimangono, ma meno visibili allo sviluppatore, e che così generano ulteriore complessità, senza parlare di sciocchezze come le prestazioni del sistema…

    Risultato pratico: un ragazzo scrive un framework in cui non si usa direttamente SQL, ma un simpatico file XML di configurazione per mappare tabelle su oggetti java, e tutti i selezionatori HR (capre, quanto chi li assume) a chiedere non qualcuno che conosca i DB e ragioni di architettura a livello di sistema, ma qualcuno che conosca quel preciso framework…
    Il framework viene adottato da centinaia di migliaia di sviluppatori, e poi passa di moda. Non necessariamente l’innovazione è sempre buona, in particolare quando è solo una moda, e le basi fondamentali hanno maggior valore.
    Come sempre bisogna saper pensare, valutare, riflettere e fare esperimenti, pensare di poter limitarsi ad applicare un framework, una metodologia, genera solo mostri, vedi Scrum ed Agile usati senza testa, solo come cerimoniale o per “rendere più produttive” persone di cui sostanzialmente non si capisce e non si rispetta il lavoro.

     

    Ci sarebbe molto altro da aggiungere, ma per oggi mi fermo qui.

Software utili per elettronica pratica

seven-segment-development-board-kit

Kikad

Software di schematic capture e sbroglio di circuito stampato gratuito open source.
Non ha alcuna limitazione di utilizzo.
Nel suo utilizzo si segue il tipico workflow per un programma di questo tipo: schematic capture, seguito da sbroglio del circuito stampato.
Include un visualizzatore di file Gerber ed una simulazione tridimensionale del modello del circuito stampato.

Versioni per Mac OSX, Windows e Linux.

Download Kikad
Sito dell’autore: Kikad

FidoCADJ

È un software per il disegno di circuiti elettrici e circuiti stampati gratuito. Funziona su Windows, Mac OSX e Linux. Non dispone di alcuna funzione automatica di sbroglio ne’ di validazione e controllo di regole di progetto per gli stampati.
Semplicissimo da utilizzare, ma richiede comunque una scorsa al manuale di istruzioni. Comodissimo per realizzare rapidamente schemi circuitali da usare su Web ed in pubblicazioni.

L’autore è l’italiano Davide Bucci, che lo ha sviluppato in modo da essere compatibile con FidoCad.
Download FidoCadJ

 

LTSpice

È la versione di Spice con annesso schematic capture realizzata da Linear Technology.  Rende l’utilizzo di Spice facile ed adatto ad un utilizzo anche didattico per utenti non esperti.
Gratuito e privo di limitazioni.
Le librerie fornite ovviamente supportano i componenti di Linear Technology, ma è possibile usarlo per simulare altri dispositivi, dato che è possibile (anche se non del tutto immediato) importare modelli di terza parte.

Download di LTSpice ed altri software Linear Technology

 

Java ed il trionfo della mediocrazia made in Italy

java-prize-for-mediocrityLa meritocrazia ed i successori di George Abnego

Java e Meritocrazia… No, non è un refuso, non intendevo scrivere meritocrazia. La mediocrazia è esattamente l’opposto del concetto di meritocrazia, è il trionfo degli uomini da riporto, gli eredi evoluti dell’uomo medio, il trionfante George Abnego. Questi pavidi eredi della specie umana  regrediscono allo stato animale e vengono addomesticati dai cani, che nel frattempo sono diventati senzienti, e gli esseri umani, con una simpatica inversione di ruoli fantascientifica, vengono utilizzati dai cani come animali da compagnia. L’unico errore dell’autore (William Tenn, “Null-P“) è l’ambientazione, non è l’America, ma l’Italia la patria di elezione dell’ Uomo Medio.

In Italia hanno vinto loro: i medi, sono quelli che sostengono sempre e comunque che “non si possa avere davvero completamente torto” su qualcosa, quelli che cercano sempre le posizioni equidistanti, quelli che non si espongono mai, i moderati.

Li riconoscete quando su Facebook dopo un post su un argomento appena un po’ controverso, per esempio su un tema come Edward Snowden, vi scrivono “io non capisco di queste cose”. Non sia mai detto che si espongano e prendano una posizione, in pubblico, se non sono già sicuri di schierarsi a favore del vincitore.

I Medi sono al governo da ben oltre 70 anni, e questo paese è alle soglie di una catastrofe finanziaria e sociale. I loro antenati sono illustri, e gli anticonformisti pensanti sono strani mutanti destinati ad un futuro incerto. “Con Francia o Spagna, purché se magna” è da sempre il motto dei Medi. Il loro attributo precipuo è quello di “tenere famiglia”. In nome dei loro pargoli sono dispostissimi a tagliarvi la gola e pugnalarvi alla schiena, il tutto senza mai abbandonare una bellissima presunzione di “superiorità morale” e magari facendovi anche una bella ramanzina sul Natale, i buoni sentimenti, e naturalmente “la famiglia”.

Nelle aziende ed in genere dovunque si prendano delle decisioni, “l’uomo medio” decide, ma con moderazione, nel dubbio non assume posizioni e si limita a fare quello che fanno tutti gli altri. Non rischia, e se anche pensa, non parla.

Per ogni problema c’è una soluzione, questa soluzione è Java 🙂

 

Non è che manchino delle alternative tecnologiche convincenti a Java, ed è ben strano che le Università Italiane, in tema di Informatica abbiano deciso di adeguarsi tutte a questo linguaggio, a fronte di esperienze assai diverse in altri paesi, che hanno visto nascere per scopi eminentemente didattici linguaggi come OCAML, prodotto dalla ricerca Francese dell’INRIA o notevoli esperimenti su Haskell, ML in paesi non così lontani. Certo, in altri paesi, per esempio, non si copia, ed è raro incontrare molte persone con stesso cognome in Università e, per non farsi mancare nulla, nel Tribunale della stessa grande città.

Da noi cosa si è scelto di fare? Formare i giovani su Java. Così, perché è l’industria del paese che ce lo chiede. Certo, ottimo, adesso finalmente abbiamo una Università che forma le professionalità richieste, peccato che sia la formazione che le richieste siano obsolete e basate su assunti di assai dubbia modernità.

Risultato: oggi tutta l’amministrazione pubblica e tutto il sistema paese Italia, di fatto utilizza applicazioni che vengono definite commerciali da Oracle, che circa sei anni fa ha acquisito Sun, l’azienda che ha progettato e diffuso Java.
Din din, si inizia a sentire il tintinnio di qualcuno che verrà scrollato, se serve a testa in giù, per far cadere le monete in suo possesso…

E’ cosa saggia usare “come monocoltura” Java in campo Informatico? Da un punto di vista di performance, e quindi economico, non può esserlo, dato che un linguaggio basato su un processore virtuale, simulato, non potrà mai essere altrettanto efficiente di un un linguaggio che compila codice nativo su un processore reale. Quindi qualsiasi strategia che utilizzi un linguaggio le cui prestazioni siano sistematicamente dominate da un altro, non può essere altrettanto scalabile, ne’ altrettanto efficiente.

Il vero problema non è in se’ Java,  che è una rispettabilissima piattaforma informatica, è la forma mentis da hoarding, che porta alla sua scelta “perché così non si può sbagliare”, tutti insieme, tutti seguendo la stessa identica moda, senza riflessione e senza aperture. E’ lo stesso fenomeno che una volta portava a scegliere IBM perché “mai nessuno è mai stato licenziato per aver scelto IBM” (cosa diventata in seguito falsa, si, i tempi cambiano, anche se lentamente).

Se realizzo un sistema su Cloud, difficile ambire ad una diffusione planetaria, se parto con Java: un mio concorrente che spende la metà quanto a risorse e tempo di calcolo, può fornire lo stesso mio servizio a metà dei miei costi….

E quando si prendono decisioni per la nazione che succede?
Iniziate a chiedervi quanto ci costano i server ed i sistemi in Java dell’Agenzia delle Entrate, che servono decine di milioni di utenti.
Davvero davvero non si poteva fare di meglio? Suvvia, ma lo avete visto come funzionano “bene” i software per le dichiarazioni?

Ed è niente rispetto alla porcheria di avere sistemi diversi, regione per regione, in nome dell’Autonomia Locale, ma soprattutto del finanziamento delle grandi società di consulenza, che realizzano non un unico sistema informatico, per esempio, per l’assistenza medica, ma tante versioni diverse quante sono le regioni: una bellissima moltiplicazione di pani e di pesci, per esempio a spese di chi ha un bar e si ammazza di lavoro da mattina presto a sera tardi per tentare affannosamente di sbarcare il lunario.

Aperto, Gratis, Multipiattaforma… oppure no?

 

Si, ma “Java è aperto, multipiattaforma e gratis!”. La frase precedente contiene tre predicati, e sono falsi tutti e tre.
Java non è aperto, perché il nucleo fondante del successo economico di Java, il compilatore HotSpot non è ne’ aperto, è basato su una tecnologia squisitamente proprietaria, ne’ tantomeno è multipiattaforma, le piattaforme su cui gira Java Hotspot non sono più di quattro o cinque, e non includono, per esempio, ARM64. Se volete utilizzare Java su MIPS, o simili (e potrebbe servirvi, per esempio in un contesto embedded), tanti auguri e tante care cose!
Senza Hotspot potete solo usare OpenJDK, e quest’ultima Virtual Machine non ha le prestazioni che ormai date per scontate quando parlate di Java, e senza le quali Java non avrebbe mai raggiunto la sua diffusione.

Inoltre, piccola ciliegina sulla torta: Java non è gratis, in particolare non lo è  Java SE. Java è gratis per lo sviluppo, cioè lo è esattamente quanto il database Oracle, che, come sviluppatori potete scaricare liberamente, ed anche utilizzare per sviluppare un sistema; ma la cui licenza commerciale vieta espressamente che possiate farci alcunché di non didattico senza pagare.
Pensavate che fosse gratis? Sbagliavate.

Open Source tua nonna…

La cosa più divertente è tutta la spocchiosa retorica Open Source su Java, che è “open source” ma a macchia di leopardo, cioè quel che basta per essere del tutto proprietario.
Ma a parte il rischio di dover pagare cifre arbitrarie per la vostra “tecnologia gratuita”, dopo averci basato sopra l’intera infrastruttura informatica del paese, Java non è a la migliore soluzione possibile, nemmeno ignorandone il costo.

Vi siete mai chiesti perché non si scrivono Web Server in Java, se non come esercizio didattico? Perché non ha senso, dato che i Web Server devono essere programmi efficienti ed affidabili.

Se non vi rendete conto che Java è meno efficiente, per esempio del C++ o di qualsiasi altro linguaggio compilato nativamente, e dite di occuparvi di informatica, probabilmente non avete una cultura informatica degna di questo nome, ed avete serie lacune nella comprensione, a livello di sistema, della tecnologia che vi circonda: probabilmente avete un titolo da “informatici”, ma non capite davvero gli strumenti che utilizzate, e siete un po’ analoghi a chi guida un’automobile, ma non ha una idea nemmeno una molto vaga di come possa funzionare uno spinterogeno.

Se non siete informatici, potrebbe anche andare bene, ma il dramma è se siete informatici e prendete decisioni su cose che non capite, perché valutate il contesto, non valutate quali sono i pregi ed i difetti di una soluzione diversa, e soprattutto non sapete che esistono alternative. Avete in mano dell’aspirina e da bravi medici, la somministrate indifferentemente sia per il mal di testa che per il diabete e per la menopausa.

Anche nell’utilizzare Java, in Italia lo si fa comunque nel modo peggiore possibile, privilegiando le soluzioni che comportino una massimizzazione delle risorse da umane da impiegare: file di configurazione XML lunghi come romanzi, e tecnologie perverse come JSF, scartando qualsiasi soluzione “semplificante”. Lo scopo non è produrre un sistema che funziona bene: è produrre il numero massimo di billable hours che si riesca, va bene per tutti: grandi società di consulenza, dirigenti (massimizzazione del curriculum: ho guidato un sacco di sottoposti), ed anche del singolo consulente (“ho massimizzato il mio curriculum, ho inserito tante keyword nel mio CV”).
Ed è contento anche il selezionatore, che già non capisce che competenze deve selezionare, quindi figurati se non sfoltisce con “preparazione su Java”, “aggiornata” e con laurea magistrale e conoscenza della lingua Inglese.

Piccola parentesi sull’HR in Italia

Suvvia, in Italia i selezionatori chiedono la conoscenza della lingua Inglese ai contabili, a cui non serve mai, tranne per le sei multinazionali che ne hanno davvero bisogno e che non usano le aziende di selezione del personale.
Glielo andate a dire voi che ad un giovane che ha iniziato a lavorare tardi, che comunque a cinquant’anni la sua carriera sarà bruciata e che non riceverà più alcuna risposta ad un suo curriculum? Si, nel frattempo l’età pensionabile si allunga, e non si capisce che prima o poi, questa cosa potrebbe diventare, come dire, appena lievemente problematica.
Sul ruolo dell’HR nella disfatta di questo paese mi dilungherò in modo più diffuso in seguito.

L’uomo medio e le alternative a Java

Nello scegliere alternative, anche quando non usano Java, gli “uomini medi” alla fine seguono sempre e comunque mode.

Per esempio ci sono dei furbastri che auspicano un maggiore utilizzo di PHP nella pubblica amministrazione al posto di Java, un po’ come suggerire di spararsi nei testicoli come cura per il mal di testa, allo scopo di vendere più proiettili se siete degli armaioli.

Sempre per esempio, solo degli sviluppatori Italiani potrebbero pensare di sostituire un back end scritto in Golang e sostituirlo con uno in Ruby, e proporlo allo scriteriato cliente di turno come “miglioramento”, sfruttandone l’analfabetismo tecnico. Lo possono fare solo in Italia, dato che non c’è nessuno che possa capire la scelta, le implicazioni, e tanto il cliente non “capisce di fatti tecnici e soprattutto non li vuole capire”. Inutile progettare un sistema ad alte prestazioni: non verrà capito, ed il prossimo “conoscente meglio introdotto” lo massacrerà senza ritegno e senza capire.

Evoluzione della specie

Forse hanno ragione i “medi”, che si adeguano a quello che il cliente davvero vuole, e quel che vuole in Italia, un paese in cui il termine meritocrazia è privo di significato, e di sicuro non premia mai, è quasi sempre solo una gratificazione del proprio ego.

Infatti più sei intelligente in Italia, tanto meno è probabile che tu abbia un lavoro non precario, e possa come conseguenza riprodurti e passare i tuoi geni:  abbiamo una selezione sistematica di idioti, una eugenetica all’incontrario, in cui alla fine sopravvivano solo figli di politici ed ammanicati è un problema neanche tanto fantascientifico in questo paese.

Questa ripeto, non è una tirata su Java, ma su un modo di fare informatica.
Identicamente e con lo stesso spirito si può fare app mobili con un qualche framework multipiattaforma, oppure si può usare iOT con disinvoltura e totale assenza di consapevolezza e di ragionamento sulle conseguenze ed implicazioni in termini di sicurezza: la ricetta è sempre quella: seguire una moda, non pensare, non riflettere, ma limitarsi a seguire il branco.

La contromisura? Fare esattamente l’opposto, cioè riflettere, ragionare e tenere una mente aperta, effettuare di tanto in tanto degli esperimenti con altre tecnologie.

Qualche riflessione su Arduino

Arduino rappresenta uno dei pochissimi casi di successo recenti della didattica sui microcontroller ed in generale sull’elettronica. Il progetto Arduino fa notizia perché un sistema di sviluppo di terza parte ha venduto qualche milione di pezzi, ed ha in parte resuscitato un mondo abbastanza morente, quello dell’elettronica digitale, in particolare vista come passione, hobby, in modo creativo. A titolo di cronaca, non mi risulta che nemmeno Texas Instruments venda così tanti sistemi di sviluppo, che di solito sono dei prodotti di nicchia.
Veramente innovativo è stato, almeno inizialmente, il suo basso prezzo rispetto alle piattaforme professionali del tempo: prima di Arduino era normale che un sistema di sviluppo per microcontroller costasse qualche centinaio di Euro. Oggi però il  prezzo è un argomento un po’ stantio, dato che esistono sistemi di sviluppo professionali, per microcontroller dell’ultima generazione, a prezzi inferiori rispetto ad un Arduino “originale”, ed a differenza di quest’ultimo parliamo di schede con tanto di debugger e processori moderni a 32 bit.

Il progetto di Arduino in se non è degno di nota quanto ad innovazione: utilizza componenti che erano già vecchi sette-otto anni fa, e l’essere basato su dei microcontroller obsoleti, ad otto bit, con una tecnologia di montaggio pass-through, componenti saldabili “a mano” da parte di appassionati è stato parte del suo successo.  Questo suo “essere obsoleto” ed a bassissimo costo, soprattutto per chi lo produce, è stata per molti versi la sua fortuna.

Arduino rappresenta anche luci ed ombre tipicamente Italiane quanto a modo di agire di chi lo ha diffuso. A parte l’elettronica, che non è niente di cui vantarsi in pubblico, il contributo più rilevante del progetto su cui si basa è il suo software, che è solo un adattamento di Wiring.

È interessante che il contributo di Wiring e del suo autore  sia stato a lungo taciuto ed ignorato, al punto da dare molto fastidio ad appassionati che lo vedono, probabilmente giustamente, come una appropriazione di un progetto open source preesistente, e suscitando numerose polemiche (basta dare una scorsa ai commenti sui forum per farsi un’idea).
Tra l’altro, appare veramente pessimo, ed in piena tradizione accademica Italica, l’appropriarsi dei frutti della ricerca di uno studente, dimenticandosi di citarlo persino nei credits per qualche tempo.

Personalmente trovo un po’ raccapricciante l’agiografia ufficiale: progettato “in un pomeriggio”, senza sforzo, con una ombra di superominismo e faciloneria tipica di chi sottostima la difficoltà di quello che non fa, infarcita di una retorica sull’open source falso perbenista piuttosto opportunista: il progetto è Open Hardware, ma ce ne si dimentica per castigare “i brutti cloni cinesi pieni di difetti”, che, quando non usano contraffazioni del marchio, hanno pieno diritto di produrre quante schede vogliono, e, per inciso, funzionano benissimo, spesso meglio dell’originale, che presenta numerosi problemi di qualità anche a livello di semplice circuito stampato (vedi per esempio i connettori male allineati).
I soci fondatori, divisi tra Fondazione e Srl Italiana sono riusciti addirittura a litigare  tra di loro sulla proprietà del marchio Arduino, a farsi causa, con esiti diversi in Italia ed altrove, per poi mettersi d’accordo e rappacificarsi: a guardarla da fuori sembra un po’ una brutta telenovela.

Visti gli ultimi sviluppi, è quindi probabilmente inutile chiamare “Genuino” Arduino in Italia, almeno sul nome.

Arduino è poco più di un giocattolo, obsoleto e limitatissimo, non utilizzabile per scopi professionali: se state utilizzando Arduino per sviluppare dei prodotti industriali che sperate si possano diffondere su larga scala, probabilmente questa è una indicazione della vostra scarsa cultura come progettisti, si c’è gente che si spaccia per firmwarista dopo aver caricato un paio di sketch e modificato qualche esempio.

Sempre recentemente, ATMEL ha iniziato a consentire di importare sketch Arduino in progetti in C++ del suo ambiente di sviluppo professionale. L’ambiente di sviluppo può anche essere professionale, ma i limiti del suo progetto rimangono, per esempio la comunità Arduino non sembra essere consapevole dell’esistenza dello standard MISRA, il che fa si che progettare sistemi che possano essere potenzialmente “sicuri per la vita umana” è a dir poco “fuori tema” quanto a scopo del progetto Arduino, che dovrebbe venire limitato ad uso didattico, artistico, e tenuto ben lontano da applicazioni in cui sia richiesta affidabilità garantita.

Non a caso,  quando si parla di utilizzo in campo industriale non posso non osservare che, per quanto validi possano essere i prodotti di Atmel, l’azienda che fabbrica i microcontroller presenti sulla board di Arduino, Atmel non è esattamente leader di settore, ed infatti è stata acquistata da Microchip Technologies (e non viceversa!). Microchip, la celebre casa dei PIC vendeva, già nel 2013 oltre un miliardo di chip all’anno, il che la ponw sullo stesso piano di altri giganti come Texas Instruments e Cypress Technology.

Oggi Arduino supporta anche delle schede basate su ARM a 32 bit, ma solo recentissimamente con Arduino M0 si è aggiunto un debugger on board, comunque non compatibile con le vecchie schede. Su Arduino o si riesce a montare un emulatore JTAG (che costa quanto una decina di schede “originali”), oppure quanto a debug si è costretti ad accontentarsi di scrivere messaggi sulla consolle seriale, come dicevo, una cosa piuttosto primitiva.
Se proprio cercate un clone di Arduino con prestazioni “moderne”, vale la pena prendere in considerazione la famiglia di schede “Nucleo” di ST.

Il linguaggio di programmazione di Arduino è in qualche modo un subset del C++, ed ispirato da Java,   il ambiente di programmazione è abbastanza semplice, ma non certo quello che ci si aspetta quando si parla di una IDE “industriale”.

Le librerie sono in genere scritte da appassionati, ed in genere si rivelano, non appena vengono aperte da un professionista, scadenti, piuttosto deludenti e di dubbia affidabilità: lunghissime funzioni scritte in “spaghetti code”, funzioni complesse interamente realizzate all’interno di un interrupt handler, non strutturato, codice scritto all’interno dei file di intestazioni e simili piacevolezze. Se pensate di poter usare Arduino all’interno di una startup che vuole fare automotive, vedo qualche criticità.

Per certi versi Arduino è un grosso regresso culturale, è la vittoria della scuola della semplificazione a scapito della cultura e della funzionalità, non sarebbe mai stato un successo negli anni 80 o 90 perché in Italia negli anni 80 o 90 la gente in Italia faceva davvero progettazione, e non era esclusivamente formata da un pubblico di consumatori spesso poco inclini allo sforzo intellettuale. Arduino è “facile”, anche nella sua didattica si saltano normalmente “concetti difficili” a costo di dare informazioni errate concettualmente: Arduino non ha alcuna “uscita analogica”, quando gli Arduinisti parlano di “porte analogiche” intendono i segnali digitali PWM, modulati in impulso, che permettono in qualche modo di regolare la potenza media, per esempio di un Led, ma non sono affatto delle uscite “analogiche”.
Se volete delle uscite “analogiche”, vi servono o tutt’altro genere di microcontroller, o degli appositi componenti esterni. Anche il linguaggio, gira intorno alle “difficoltà”: non si parla di programmi, ma di Sketch, quasi che scrivere uno sketch non sia la stessa cosa dello scrivere un programma.

Anche se la qualità delle librerie è non molto alta, per mettere insieme in quattro e quattr’otto un qualche accrocchio, quanto al “farlo in fretta”,  quasi sicuramente si vince con Arduino, lo sviluppo con l’ambiente di sviluppo di un microcontroller industriale è di maggior difficoltà, ma poi le prestazioni possono essere assai diverse: minore spazio, minori consumi, maggiore controllo, maggiore affidabilità.

Arduino può andare bene per un primo contatto con l’elettronica, ma è triste non riuscire a crescere ed andare oltre. Ciò detto, se volete un approccio facile, iniziate pure con Arduino, ma non pensate di rimanere solo a quello tutta la vostra vita di progettisti di sistemi digitali, si spera che “da grandi”, facciate altro.