Incentivi statali
Se l’obiettivo dell’incentivo statale all’acquisto delle automobili di nuova generazione è di diminuire l’impatto ambientale degli spostamenti degli italiani, dovrebbe esistere anche un incentivo all’eliminazione dell’automobile.
Rottama la tua vecchia auto e accetta di non poter acquistare nessuna nuova auto per i prossimi 4 anni: lo stato ti dà fino a 3.000 euro. Perchè i soldi? per incentivo a spenderli in mezzi pubblici.
Cosa sei disposto a perdere?
Siamo bombardati di offerte “green”. è il problema e la moda del momento, per cui qualunque prodotto, dall’automobile alla scatola di pelati, va sul mercato proclamando quanto è sensibile all’ambiente (una volta si diceva natura, ma è troppo old-style), quanto è riciclabile e quanta energia rinnovabile ha consumato per essere prodotto.
Chi non riesce a produrre green, nemmeno a scriverlo sull’etichetta, esce con le linee guida. manualetti che dicono come usare bene il prodotto. Ecco che i produttori di energia consigliano di comprare lampadine a basso consumo, distributori di acqua potabile consigliano di usarne meno, eccetera.
Comincerei però a chiedermi cosa siamo veramente disposti a perdere in nome della protezione dell’ambiente. dobbiamo convincerci che proprio ciò che più ci è comodo è ciò che più inquina. comprare un auto ecologica è buono, non usarla è meglio.
Qualcosa già perdiamo, e sono soldi, attraverso i finanziamenti, stanziamenti e incentivi che sostengono le varie iniziative. non basta secondo me ed è superficiale considerare questi incentivi positivi a prescindere. Leggevo dei dati sulla relazione tra tonnellate di co2 prodotte e milioni di euro di PIL: 111 tonnellate di CO2 ogni milione di euro di PIL. Morale: produrre denaro inquina. Io per produrre il mio stipendio uso la macchina, il pc, la corrente elettrica. 1000 euro costano 111 kili di co2. Significa che se installare un pannello solare costa 10.000 euro, nel suo ciclo di vita deve almeno evitare (evitando l’uso di energia elettrica da fonti tradizionali) che siano prodotti 1110 kili di co2. E’ vero? indaghero’. ma lo stesso ragionamento si dovrebbe applicare ai 2000 euro di incentivo all’acquisto di auto ecologiche, alle detrazioni per l’acquisto di caldaie, eccetera.
Perdere i soldi in nome dell’ambiente è una condizione che siamo disposti ad accettare. Tanto più se sono soldi dello stato. sono nostri, ma sono ormai così lontani dalle nostre tasche che accettiamo di buon grado di spenderli (un po’ come l’effetto carta di credito, per cui se non tocchiamo la banconota fisicamente, siamo più disponibili a spenderla). Siamo sicuramente meno disposti a perdere altre comodità. L’auto, la luce sempre accesa, il bagno abbondante, il lenzuolo bianco, il cioccolato ecuadoregno (e che sia l’80% senno’ non mi piace), la lavastoviglie, la pasta che bolle in 1 minuto, e avanti così. provo a elencare qualcosa:
- auto. sono disposto ad andare a piedi al metro’. sono 15 minuti di camminata. ma solo quando c’è il sole. quando piove, arrivo zuppo al lavoro e non è accettabile. ma come facevano i nostri nonni che andavano al lavoro in bici? glielo chiederò.
- luce: perchè ho comprato per il salotto quelle belle lampade satinate? dentro hanno tre lampadine alogene da 70 watt. accidenti però, ‘ste lampadine a basso consumo ci mettono una vita (ben 1 secondo!) ad accendersi. insopportabili (!)
- bagno: bello farsi il bagno ricoperti d’acqua. quanti litri sono? boh, troppo difficile misurarli, la vasca non è un parallelepipedo, altrimenti sarei capace di calcolare il volume. ci vorrebbe un misuratore di litri d’acqua inserito nel rompigoccia.
- lenzuolo: perchè deve essere bianco. il cotone in natura è grigio. costa sbiancarli e costa tenerli bianchi. perchè non lanciamo la moda del lenzuolo colore naturale?
- il cioccolato: voglio bene agli ecuadoregni, hanno un’economia basata (tra l’altro) sul cacao. ma proprio non possiamo accontentarci delle nocciole, che crescono da noi?
- la lavastoviglie: conviene usarla, è vero, ma magari conviene solo quando si lava il servizio da 12. se mettessimo i litri d’acqua che consuma in una bacinella, forse ci renderemmo conto che per lavare i piatti e le pentole della sera (spesso è sufficiente un getto d’acqua, senza quasi strofinare) basterebbe una passata nel lavandino.
- la pentola che bolle in un minuto: ho preso un piano cottura con 5 fuochi. quello centrale ha 3 corone, come quello dei grandi ristoranti, così l’acqua bolle prima. ma quanto gas consuma?
- l’ascensore: se mettessimo l’ascensore a monete (anzichè dividere la spesa per l’energia elettrica tra i condomini) forse ci renderemmo piu’ conto di quanto costa e magari lo useremmo di meno.
Chi deve essere disposto a perdere però non deve essere solo il singolo quando è a casa. sarebbe troppo facile. deve esserlo anche il singolo quando va al lavoro, dipendente o imprenditore che sia. ancora qualche esempio:
- l’enel non chieda aiuti dallo stato se c’è un calo dei consumi (notizia di qualche mese fa). non dovremmo essere tutti contenti di questo fatto?
- le aziende di servizi (società di consulenza) dichiarino che tutti i viaggi dal cliente saranno fatti il più possibile con i mezzi pubblici (no, i taxi non sono mezzi pubblici). se ci si metterà mezz’ora anzichè un quarto d’ora, il costo derivante dalla differenza di tempo sarà spartito a metà tra il cliente e il fornitore.
- eliminiamo i condizionatori dagli uffici, anche quelli della direzione
- oltre ai buoni pasto, diamo i buoni viaggio. spendibili solo sui mezzi pubblici.
- le luci devono essere spente di default, e accese solo quando c’è veramente qualcuno.
stare coi piedi all’asciutto
Non ho ancora capito dove mi possa condurre questa osservazione, ma ieri sera ho notato che quando piove e la strada è piena di pozze, il posto migliore per stare coi piedi asciutti è il centro di un tombino.
Finito il buffer?
E’ un periodo che sono in affanno. Ho il buffer pieno.
Immaginiamo un meccanico. Normalmente prende in carico da un cliente una vettura e fissa una data di riconsegna. tra questi due momenti, sa che dovrà dedicare alcune ore al lavoro sulla vettura, in modo che, per tutte le vetture che ha da sistemare, siano rispettati i tempi di consegna. Non è complicato. tutti i meccanici convivono con questo sistema. Il meccanico in genere tiene anche un po’ di margine negli impegni della giornata, per gestire le emergenze, le richieste improvvise di clienti storici, una riparazione più complicata del previsto. E’ quello che chiamo il buffer personale. Tenere questo buffer in modo equilibrato consente di svolgere tutto il proprio lavoro e anche le emergenze. e a volte di respirare.
Cosa succede se a un certo punto il meccanico riempie il buffer? succede che alla prima emergenza si trova obbligato a far slittare il piano dei lavori. E così comincia a lavorare alle vetture un quarto d’ora prima che arrivi il cliente, giusto giusto in tempo per consegnargliela, oppure per consegnargliela quei 5 minuti di ritardo che il cliente sopporta.
Il problema è che i clienti non sempre sopportano i 5 minuti di ritardo, le emergenze continuano a esserci e, soprattutto, il meccanico è costantemente in affanno.
Mi sono accorto che è un bel periodo che lavoro come questo meccanico. Tempi al limite, qualità e concentrazione sparpagliate su troppe cose e quindi al minimo. Sto cercando un modo per cambiare passo. Vorrei riuscire a dedicare il giusto tempo e la giusta lucidità alle cose. O meglio, di affrontare le cose con il giusto anticipo, in modo tale da lavorarci con la mente libera e quindi con la giusta qualità.
Sono convinto che si possa lavorare con meno affanno, ma mantenendo i ritmi elevati, solamente cambiando il modo in cui si affrontano i lavori, le urgenze, e anche i ritardi.
Qualcuno mi ha detto che è sufficiente non pensare a ciò che si sta facendo. Semplicemente non pensare a nulla. L’idea è che per concentrarsi in modo efficace su una cosa, senza crollare sotto le altre 10 cose in ballo, è non concentrarsi su nulla in particolare.
ci devo ragionare. con calma.
La mia visione romantica della consulenza
Come probabilmente è già emerso in qualcuno dei miei altri post, ho una visione direi cavalleresca della consulenza. Almeno per quanto riguarda la consulenza che vivo ogni giorno, quella nel settore dell’Information Technology.
Un po’ come un cavaliere dei tempi andati, sento che esiste un insieme di principi forti a cui è importante attenersi per essere degnamente nel campo dei professionisti. Chiamiamola etica professionale, o deontologia, io mi tengo la mia coscienza e cerco di coltivarla ogni giorno.
In questo mio mondo di draghi e fate, la consulenza è un servizio offerto da un professionista, e il suo costo è la remunerazione per il suo lavoro.
Il valore percepito e la soddisfazione del cliente sono cio’ che guida il consulente, che fa sempre del suo meglio per dare al cliente cio’ che si aspetta.
Entrambi sanno sempre che c’è del denaro in ballo. Il consulente con questo si ricorda sempre che ciò che fa è un lavoro, non volontariato, e per questo ha dei doveri e non sempre gli capita la fortuna di far cose che gli piacciono. Allo stesso tempo, il cliente si ricorda sempre che ha davanti a sè un professionista, non un volontario o peggio un servo.
Fortissimo valore ha il rispetto. Il cliente rispetta il consulente e le sue competenze. Il consulente non è visto come un capro su cui riversare eventuali colpe, non viene usato per difendere o supportare posizioni, non viene preso come l’esecutore dei lavori sporchi.
Ma soprattutto il consulente rispetta il cliente. Il cliente non è mai una vacca da mungere, nè l’ignorante da gabbare con superiorità.
Il consulente non finge mai di avere una soluzione a tutto, nè di avere competenze su tutto. Analogamente, il cliente non si aspetta la soluzione a tutto, nè di avere a che fare con un onnisciente. Entrambi sanno sempre però che il consulente fa ogni giorno del suo meglio per risolvere il problema del cliente, qualunque esso sia, anche quando in partenza non ha la minima idea di come farlo. Così il consulente non ha problemi a dichiarare che per risolvere il suo problema, il cliente dovrebbe rivolgersi a un altro, e il cliente apprezza questo gesto come un prezioso suggerimento da parte di un collaboratore che non lo sta fregando.
Il cliente non ha problemi nemmeno a dire che si sta rivolgendo a un altro, instaurando un meccanismo sano di concorrenza leale, in cui il cliente segue il suo giusto interesse assegnando il lavoro al collaboratore più adatto.
Il sunto della visione può essere che cliente e consulente sono dei collaboratori paritari e il loro rapporto è fondato sul reciproco rispetto dei ruoli, delle competenze e delle esigenze.
La consulenza e la tinteggiatura
Nell’ultimo periodo ho imbiancato casa. Non essendo un professionista imbianchino, e soprattutto essendo la prima volta che lo facevo, ho distribuito nel tempo (nei vari ponti primaverili) le varie stanze della casa.
Essendo la prima volta, ho iniziato con una visita al più vicino castorama per capire i prodotti, gli attrezzi, le possibilità. E mi sono trovato spiazzato dalla varietà di prodotti. Tutti sembrano l’ottimo per la mia stanza. Peggio ancora, per quelle stanze in cui la moglie ha chiesto il colore, decine di materiali diversi con promesse di mirabolanti effetti con una passata di rullo/spugna/straccio/spatola.
Come profetizzo con i giovani in cui incappo su lavoro, in questi casi si cerca un esperto. Mi rivolgo a mio padre e a mio suocero, esperti per pratica piuttosto che per professione. La risposta che ottengo è “dipende”. Per prima cosa bisogna capire che tipo di muro è, poi che tipo di pittura è stata data l’ultima volta, poi che tipo di risultato voglio ottenere. Poi bagno e cucina sono diversi dalle altre stanze, ma anche tra le altre stanze ci possono essere differenze. Ho ottenuto un aumento mostruoso della complessità, senza risolvere il mio problema.
Io ho un muro normale (come si capisce che muro è?), non so cosa è stato dato l’ultima volta perchè non l’ho fatto io e non ero ancora entrato in casa, voglio un risultato normale (un muro pitturato, bianco da qualche parte, colorato da altre), mi sembra ragionevole di non volere che crescano muffe o piante nel bagno (c’è qualcuno che invece le cerca, che non sia un botanico malato?). C’è bisogno proprio di chiamare la scientifica per comprare una tolla di vernice?
Ho risolto comprando un libriccino da due soldi, qualcosa tipo “il manuale dell’imbianchino”, in cui in una decina di pagine mi viene data la lista della spesa per gli attrezzi e i passi (pochi e ben definiti) da fare per imbiancare una stanza, dalla preparazione all’asciugatura. Poi nei capitoli successivi, si addentra invece nei casi particolari: hai un muro ammuffito? hai delle crepe? vuoi la cappella sistina?
Ecco, provo a declinarlo nel mondo della consulenza. Troppo spesso da consulenti diamo la risposta “dipende” quando un cliente ci chiede una indicazione su una soluzione, una tecnologia, un prodotto. “dipende” è sicuramente la risposta più corretta, perchè è vero che dipende, ma non serve assolutamente a nulla al cliente. La risposta più utile sarebbe un qualcosa tipo “nel 70% dei casi funziona bene così”. Questo porta ovviamente il rischio che il cliente ci ringrazi e non ci dia altri soldi. In fin dei conti aumentare la complessità di un problema dà lavoro, perchè bisogna fare la valutazione del contesto di partenza, bisogna capire i reali bisogni, bisogna definire un modello obiettivo e poi definire la strada per raggiungerlo. Tanto lavoro. Soldi non spesi male sicuramente, perchè è l’approccio migliore per capire di cosa si ha bisogno. Ma in quel preciso momento in cui il cliente chiede una opinione, il “dipende” lascia tutto in sospeso e non serve a nessuno.
E’ corretto (anche per le tasche del consulente 😉 che si avverta poi il cliente di cosa significherebbe prendere per buona alla cieca la risposta standard. E’ vero che funziona nel 70% dei casi, ma se questo caso non fosse standard, che danni farebbe adottare la soluzione standard? Si potrebbe scoprire che non ci si smena poi tanto, ma si potrebbe anche scoprire che il rischio non vale correrlo e allora procedere con una analisi attenta.
Da qui emerge una indicazione per un approccio che consentirebbe di risparmiare soprattutto tempo. Il primo passo per provare a risolvere un problema è prendere una soluzione standard e capire se funziona e che rischio corro ad adottarla. Se mi va bene, in pochissimo tempo ho dato una soluzione al cliente, altrimenti procedo in modo classico con una valutazione approfondita del contesto e delle alternative tecnologiche.
Un’ultima nota, spesso da consulente ho usato la risposta “dipende” per prendere tempo su temi che non padroneggiavo. Vorrei ripromettermi di evitarla in futuro. Ci provo.
Ancora sui file di testo
Una precisazione. La mia non vuole essere una campagna contro i file di testo, nè verso il loro utilizzo come mezzo per la memorizzazione del codice sorgente. La mia critica è che anche linguaggi e strumenti di programmazione di alto livello portano ancora oggi il fardello del legame con la rappresentazione fisica del sorgente. Vorrei un maggiore disaccoppiamento tra ciò che lo sviluppatore manipola e la sua rappresentazione fisica. Tale disaccoppiamento darebbe forti vantaggi a entrambi gli aspetti.
Linguaggi di programmazione e file di testo
Nella stragrande maggioranza dei contesti di sviluppo software programmare significa scrivere testo. Non è sorprendente, visto che il codice sorgente è un mezzo per comunicare. L’evoluzione della programmazione è passata dal linguaggio macchina puramente binario a un linguaggio, ancora macchina, basato su mnemonici che ricordavano quanto meno l’operazione svolta. Il salto verso linguaggi di successive generazioni non ha fatto altro che alzare l’astrazione, avvicinando le espressioni e i termini utilizzati dai programmatori verso concetti più vicini al modo di esprimersi umani (ho detto esprimersi volutamente, anzichè pensare). l’evoluzione è rimasta finora legata alla parola e credo ci siano forti motivazioni per questo.
negli anni il testo del codice sorgente del sw è stato inserito all’interno di file di testo, con indubbi vantaggi. i file di testo si editano facilmente con programmi elementari che si trovano ovunque. i file di testo possono essere manipolati facilmente dai compilatori e dagli analizzatori sintattici.
l’osservazione che voglio fare è che la rappresentazione fisica del testo del codice sorgente è da sempre il file di testo, ma oggi non c’è più una motivazione a questo e il tempo è maturo per eliminare vincoli e side effect di questo legame. gli strumenti utilizzati dagli sviluppatori sono sempre più grafici e la potenza di calcolo consente di gestire una vera astrazione tra cio’ con cui lo sviluppatore ha a che fare (il testo o quel che sia il sorgente) e la sua rappresentazione fisica.
Quel che voglio discutere è che l’utilizzo di un file di testo per rappresentare il codice sorgente è stato in passato una scelta obbligata dai mezzi utilizzati dagli sviluppatori per creare il codice. Oggi questo vincolo è giustificato solo dalla storia.
Scrivere codice in un file di testo ha portato a un sacco di conseguenze che molti sviluppatori danno, senza motivo, per scontate:
- il codice viene letto dallo sviluppatore sequenzialmente. non interamente, ma comunque si viene portati a leggerlo dall’alto verso il basso. Strutture non sequenziali (condizioni, cicli) vengono per forza appiattite. metodi e funzioni vengono messi involontariamente in ordine.
- L’eredità dei parser di file di testo è che la posizione nel file di testo (non nella struttura come sarebbe più corretto) di un comando spesso determina un comportamento diverso.
- Gli sviluppatori si sono creati nel tempo convenzioni di tabulazione per facilitare la lettura e best practice di leggibilità (80 caratteri!!!!!) determinate dai display di 20 anni fa.
- Le grammatiche stesse dei linguaggi di programmazione impongono l’utilizzo dei file di testo per demarcare porzioni di codice e della struttura del software.
- alcuni linguaggi di programmazione hanno fatto di regole di tabulazione delle regole grammaticali vere e proprie.
- i limiti degli strumenti di sviluppo sono spesso legati alla struttura dei file di testo del codice
se oggi dovessimo inventare uno strumento per sviluppare software (attenzione, non ho detto per scrivere codice!) cosa proporremmo? il testo è indubbiamente un canale di comunicazione estremamente immediato per l’essere umano, ma dobbiamo per forza legarci a un file di testo? non è possibile pensare al codice sorgente come un mare indistinto di porzioni piccole di testo che si integrano a formare la base di codice di un sw? non cadremmo sicuramente nell’errore di considerare il confine del file di testo come un confine del sw, come spesso accade. certo perderemmo la possibilità di utilizzare uno stupido editor di testi per lavorare sul codice, ma non è forse meglio è più efficace avere un ambiente di sviluppo che dia tutti gli strumenti necessari a navigare nel codice, facendoci dimenticare della rappresentazione fisica del sorgente?
lancio quindi la proposta: proviamo a elencare gli scenari e le possibilità che si potrebbero avere abbandonando il vincolo legato alla memorizzazione su file di testo?
io e il sw
Inauguro questa nuova categoria con una giustificazione. Chiedo venia se sfioro un nuovo meta.
Ho iniziato la mia carriera nello sviluppo del sw nel 1995. Non proprio la carriera, poichè ci sono entrato da studente all’istituto tecnico. ok, i primi 5 anni sono passati con poca significatività. Sufficienti a formarmi su Turbo Pascal e Assembler. Good. I fondamenti di ciò che so ora li ho appresi in quel momento. Gran finale con una tesina di maturità (vecchia maniera) sull’Object Orientation. Col senno di poi, non ci avevo capito granchè. Bertrand Meyer non era facile come autodidatta. L’ho apprezzato solo in seguito.
I primi due anni di università ho rischiato di retrocedere. Si esce dalle superiori pensando di saper tutto, si trova un’università che non riesce a smentirti. Tristezza. Una inutile esperienza in Modula2 e una inesistente preparazione su C++.
Terzo anno, un corso su Java, il primo progettino serio. Oh. Negli anni seguenti infilo tutti gli esami possibili con un progettino di sviluppo. Gioco con il Lisp. Conosco il mondo del web sviluppato in Java con le servlet e le jhtml (quando ancora le jsp si chiamavano così).
Inizio a lavorare alla ME&S, una microsocietà di sw specializzata in strumenti di eLearning che lavora con Toolbook, una piattaforma di RAD per elearning con un linguaggio di scripting estremamente vivace. Evviva, imparo cosa significa lavorare nell’informatica e cos’è la consulenza. è il 1998. Qui proseguirò a sviluppare in Java. Qui nel 1999/2000 ci convertiamo tutti al Javascript. Venivamo dal mondo di Toolbook, interattivo, multimediale (era un concorrente di Director, l’antesignano di Flash). Non potevamo che cercare di fare altrettanto con Javascript. Ed ecco che in quei lontani anni sviluppiamo applicazioni Javascript che farebbero impallidire una applicazione AJax moderna. Qui nasce tutto il mio sapere Javascript e tutto cio’ che oggi mi consente di parlare a braccio di come funziona un browser.
Dopo aver mollato una tesi mezza iniziata di intelligenza artificiale, mi infilo in una tesi sul sw testing, per la quale anzichè far testing devo sviluppare una gran applicazione in C++. Un tool per la generazione automatica di casi di test che integra un pre-compilatore, un esecutore simbolico, un valutatore di espressioni algebriche, un analizzatore di grafi e forse altro che ho rimosso.
Sviluppo la tesi in contemporanea con il master IT del CEFRIEL e mi guadagno due titoli con una fava. a fine master, inizio a lavorare al CEFRIEL nell’area di Ingegneria del Software. Coltivo una specializzazione sulla piattaforma Java Enterprise, su cui tengo un po’ di corsi sia in CEFRIEL sia in Politecnico. Approfitto di un progetto per giocare anche con la piattaforma Eclipse e prendermi un po’ di competenze anche nello sviluppo su architetture a plugin.
Col tempo, perdo dimestichezza col C++. Nel 2005 però derivo dal mondo Java per circa 4 mesi, sviluppando in C# una architettura per l’integrazione di strumenti di domotica sul Windows Media Center. Si parla di Universal Plug & Play.
Lascio il C# e mi infilo nel Python per un po’ di 2006. si sviluppa (giocando anche con Scrum) una piattaforma per la predizione di flussi di traffico sulla rete di milano. Non male.
Ultimamente ho perso un po’ il ritmo, poichè son passato dalla parte oscura della forza (sono PM). Non mi va di aspettare oltre a dir la mia. Oltre suonerebbe solo come un rimpianto. Spero valga il penny.
Il blog di Giordano Sassaroli 