Lacrime nella pioggia

Riprogrammare una cultura

Prendo spunto da un vecchio post di Programmatori Dentro: arguto e brillante blog di Giovanni Cuccu. Il post, nello specifico, tratta la situazione dello stipendio del “programmatore italiano”. Ve ne consiglio la lettura.

Il mercato dei programmatori in Italia? Trieste quadretto di sottopagati impiegati d’ufficio. Troppo stringato? Ok, approfondisco.

Se torniamo al concetto già espresso in questo blog, cioè che scrivere software non è ingegneria, allora si deve far valere anche la regola che è terribilmente complesso quantificare il lavoro di uno sviluppatore.

Nel post di Giovanni, e relativi commenti, si evincono stipendi imbarazzanti. Credo però che, ancora una volta, le responsabilità siano da ricondurre alla natura superficiale di questa nostra Italietta, la patria del Null Management.

Null Management
noto come Nil Management ai programmatori Smalltalk e Obj-C ;-)

Il Null Management, questa capacità tutta italiana di dirigere qualcosa di cui non si conosce assolutamente nulla, è in naturale rotta di collisione con il cargo di mestieri “veri”, con i pragmatismi di chi ogni giorno trova le soluzioni: programmatori, designer, tecnici.

Il Management è una cosa seria, lo so, ma lo è solo quando stratificato, compartimentato. Non funziona se il Manager è posizionato al top della filiera e tratta le questioni con i designer e gli sviluppatori. E’ il Project Manager dove sta? E la separazione tra design, sviluppo e testing? Se n’è visti troppi di prodotti dove l’interfaccia è progettata dallo sviluppatore o, ancora peggio, da un top manager.

Meno chiacchiere, più fare, e soprattutto non riversare sull’operativo le carenze manageriali.

Siamo noi

Diciamoci una verità. Il mercato del lavoro nel nostro paese è messo come è messo anche per causa nostra. Alcune dimostrazioni:

• Una gara per la fornitura di un sito web con prezzi attorno ai 5.000 Euro, ed ecco sbucare l’offerta da 500;
• La richiesta, da parte di un grossa azienda nazionale, per lo sviluppo di un progetto in out-sourcing. Offerte da 25 Euro/ora, quando la natura del cliente e del progetto chiamerebbero per cifre tra i 70 e i 100 Euro.

Far capire che questo lavoro vale e conseguentemente costa, è questione culturale. Non possiamo spiegare ad un Manager, ad un cliente, i tecnicismi e le complesse meccaniche dietro allo sviluppo software. Se potessimo farlo, non sarebbero poi così complesse. Non possiamo mostrare i sorgenti per far capire quanto vale questo lavoro; è necessario utilizzare l’unico metro di valutazione che queste persone capiscono: il denaro.

Non solo il denaro a dire il vero; c’è anche il tempo. Anche qui si casca nell’errore di chi, in buona fede, vuole trarre beneficio dalle proprie capacità e solo da quelle, senza sotterfugi e furberie.

Se si pensa di impiegare 50 ore, questa è l’esatta quantità che, solitamente, si espone al proprio di datore di lavoro o al proprio cliente. Grave errore. Alle 50 ore è necessario aggiungere il testing, gli imprevisti, la legge di Murphy, le decine di obiezioni del tipo “ma quello lo metterei lì”, “pensavo che potremmo aggiungere…”, “già che ci siamo…”.

Usiamo tranquillamente la regola del 3x. 150 ore quindi.

E’ cultura, non mi stancherò mai di affermarlo. Se continuiamo a concedere alle persone l’espressione “programmino”, sarà lecito pure continuare ad accettare i 1.200 Euro netti. Così come quando risponderemo “si” alla domanda “tanto è facile da fare no?”.

Isoliamo chi distrugge i prezzi, magari solo perché a 25 anni vive ancora con i suoi e non ha problemi di spese, oppure chi lo fa sfornando decine di progetti al mese sottopagati in out-sourcing. Come si possono isolare? Semplice: con la qualità. Lasciate che usino Joomla, lasciateli ai templates, lasciateli alla loro spasmodica ricerca dei componenti anche quando non è il componente che farà la differenza.

Lo sviluppo in proprio

Quelli bravi (e a volte i disperati) tentano la carta della propria software house e il più delle volte falliscono. Falliscono per 101 ragioni e quasi mai riconducibili a loro mancanze:

• le banche italiane non finanziano progetti, tanto meno quelli software
• le aziende piccole hanno bisogno di spendere poco inizialmente, anche sul personale, quindi cercano sviluppatori freschi di studio, ma le scuole di questo paese non sfornano programmatori, ma superficiali conoscitori dell’IT
• ricerca e sviluppo sono sempre messe in secondo piano (anche nelle grosse aziende), benché siano il motore che consente la penetrazione di mercato con prodotti innovativi

In assenza di finanziamenti significativi, quelli che possano garantire uno startup di 18-24 mesi insomma, l’unica strada è la collaborazione. Piccoli network, cooperative mirate su un progetto. Se e quando il prodotto sarà sul mercato, ci sarà il tempo e il modo di dare forma ad una figura aziendale.

Il gruppo

Costruire un gruppo; partorire un progetto in seno al gruppo; elevare il progetto a ruolo di star: il vero protagonista. La devozione del gruppo al progetto. Abnegazione pura. Ognuno nel Team apporta i dettagli originati dalle proprie bravure, idee, ma è il Team il motore.

Anche questo è un limite italiano. Il gruppo manca quasi sempre.

Manca nelle aziende, dove è un assembramento di dipendenti, non un gruppo.

Manca nelle collaborazioni professionali, dove l’interesse è di ogni singolo e per se.

Quindi?

Io non ho ricette. Ho solo la mia esperienza. Trent’anni di sconfinata passione, tra successi, fallimenti, soddisfazioni, delusioni, ma un comune denominatore: fatica.

Fatica nel far capire che i lavoro costa e che non c’è nulla di facile. Fatica nel sopportare la visione dei danni apportati al mio mestiere da chi a volte me ne fa vergognare. Fatica nel trattenere l’istintiva intolleranza per chi chiacchiera e gira sempre attorno al fare, senza mai raggiungerlo. Va da sé che la fatica è sempre stata in quel che ruota attorno a questo mestiere e mai nel lavoro in se. Significa quindi che se qualcosa è da cambiare, è al di fuori.

Apparteniamo a quel privilegiato gruppo di persone che, nelle loro piccole grandi realizzazioni, il mondo lo migliora un po’ tutti i giorni, perché il software è nei gesti quotidiani di tutti ormai, persino di quelli che affermano di odiare i computer, mentre controllano l’appuntamento sul proprio palmare.

A chi inizia ora, non posso consigliare di prendere di petto il mercato e soprattutto i datori di lavoro. E’ possibile però lavorare sull’immagine che questi ultimi hanno del nostro mestiere. Ancora, se pensate che il quibus non valga il vostro valore, cercate le collaborazioni e provate a lasciare la strada vecchia per la nuova, verso nicchie di mercato, nuove tecnologie. Insomma, parlando la nostra lingua, .Net e Java sono solidi roccaforti (mi hanno fatto lavorare tanto e bene), ma distinguersi può far rivivere passioni assopite e soprattutto creare nuovi spazi nel marcato.

La progettazione software non è ingegneria

Jim Reekes:

E’ una contraddizione in termini. L’ingegneria software non è di fatto ingegneria. E’ arte creativa, realizzata da artisti e artigiani, ma decisamente non da ingegneri.

Questa citazione, tratta da un’Intervista fatta a One More Thing, rispecchia totalmente il mio modo di vedere l’argomento dello sviluppo software.

Spesso si associa questa disciplina all’istinto matematico e alla logica, perdendo di vista la natura creativa e ispirazionale dietro alla progettazione e realizzazione di un prodotto software. Ci sono elementi tecnici e nozionistici alla base, certo, così come nella musica ci sono le regole fisiche e convenzionali che la regolano; così come nella pittura ci sono le tecniche che ne consentono la messa in pratica. Stessa cosa per la fotografia, la poesia, la danza.
L’espressione artistica ha sempre un sottosuolo tecnico. Quando però le nozioni sono acquisite, diventano parte di noi e lasciano spazio alla sola arte creativa. Tutti i tecnicismi scompaiono, diventato degli strumenti, il mezzo e mai il fine.

La cultura provinciale di questo Paese da sempre interpreta la laurea come un obbiettivo sociale, talvolta culturale e molto raramente individuale. A questo è da aggiungere un basso profilo in termini programmatici e didattici in termini di software.
Il risultato è, anno dopo anno, sfornate di “dottori” che il più delle volte offendono la natura creativa di questa disciplina. Applicazioni software senza design, interfacce tristi, intrise della loro logica estrema quanto inutile. Oltreoceano, perlomeno, il valore di un designer bravo è quanto quello di un ingegnere bravo, così come quello di un non laureato bravo. La chiave è “bravo”, non “ingegnere”. Il livello del software è alto grazie ai talenti, non alle qualifiche.

L’affermazione di Reekes, che italiano non è, ci riporta però alla natura, universale, del problema; alla necessità cioè di esiliare l’idea che lo sviluppo software è materia di ingegneria.

Un modesto consiglio alle nuove generazioni di sviluppatori software: meno matematica, più filosofia.

Togliere, non aggiungere

I più troveranno contro natura l’affermazione. Invece io vedo questa come la lezione più importate appresa in questi anni.

La vedo nel mia vita come nel mio lavoro, che poi sono parti del medesimo insieme.

Da giovani

Da giovani si pensa a mettere quanto più si può.

Se si è designer o grafici, si cerca il bello (e spesso lo si ottiene) nella quantità.
Se si è sviluppatori di software, si mettono quante più funzioni possibili, certi che l’utente ce ne sarà grato.

Da non-più-giovani

…ma neanche vecchi, trovo affascinante cercare di togliere quel che è in più. Quello che, pur togliendolo, non cambierà il risultato.

Se si è designer o grafici, cercheremo le linee fondamentali per inviare il segnale, senza nulla più. Sarà solo più difficile spiegare al cliente perché abbiamo usato un solo font, o meno di 5 colori..
Se si è sviluppatori di software e perdutamente fan dei nostri clienti, cercheremo di applicare la regola dell’80-20.

Regola dell’80-20

“Nello sviluppo di un’applicazione, mira a soddisfare l’80% dei possibili utenti, non il 100%. “

Per il restante 20% avremo 3 possibili soluzioni*:

1. Non fare nulla. Qualche altro prodotto nel mercato penserà a loro.
2. Sviluppare un’applicazione apposita, naturalmente cercando di accontentare l’80% di quel 20%.
3. Inserire nella nostra applicazione le funzioni avanzate, ma in modo non invasivo, quasi nascosto.

Il punto 3 rientra nella categoria delle Missioni Impossibili, quindi non fatelo.

Tirare le somme

Superfluo sottolineare che la regola dell’80-20 è applicabile e dovrebbe essere applicata per qualsiasi disciplina creativa.

Togliere è più faticoso dell’aggiungere; così come creare silenzio è più difficile che provocare rumore.

Ci vuole tempo, ma si può fare.

*Alcuni ottimi esempi della regola dell’80-20:

• iPhoto (80%) e Aperture (20%)
• iMovie (80%) e Final Cut (20%)
• Garageband (80%), Logic Express (0,2*0,8=16%), Logic Studio (0,2*0,2=4%)

Il mio primo giorno di scuola

…pare strano ma risale a non molto tempo fa.

Era il 2005 o giù di lì. Vagavo in uno dei tanti progetti in corso, sviluppato con uno dei tanti linguaggi di uno dei tanti framework al mondo. Da poco stavo familiarizzando, un po’ per gioco, con il Mac della nuova era, dopo 15 anni di militanza in Windows e prima ancora DOS e UNIX prima di lui.

Il Mac affascina chiunque, ammettiamolo; anche i geek che più geek non ce n’è, chiusi nella loro cameretta un po’ maleodorante, con il PC con chassis di dubbio stile e costantemente aperto, pronto al prossimo “taroccamento”.

Ma come ogni addetto ai lavori sa “il Mac è per i grafici, i musicisti, i giornalisti”. Quando si parla di strumenti di sviluppo, linguaggi e frameworks, allora la faccenda cambia e il PC diventa l’indiscusso padrone della scena.

Ma chi sapeva che in casa Apple, negli ultimi sette-otto anni qualcosa di realmente nuovo era accaduto? Una sorta di renaissance dalle ceneri di un rogo che aveva quasi consumato i fasti dell’Apple II (1977) e del primo Macintosh (1984). Con l’acquisizione di NeXT, Apple non solo riportò all’ovile il suo fondatore Jobs, ma soprattutto acquisì una tecnologia, quella del sistema operativo NextStep che, a cavallo tra gli anni ’80 e ’90, era anni luce avanti a qualsiasi altra tecnologia software. L’attuale Mac OS X è quindi il diretto discendente di quella tecnologia e ne eredita le meraviglie, naturalmente con un vestito tutto nuovo. Ma io, appunto, non lo sapevo.

Quasi per caso mi imbattei in una guida on-line di Cocoa e Objective-C; fu amore.

Ricordai le teorie software dei miei primi studi e di quanto fossero distanti dalla pratica della programmazione “di tutti i giorni”: il modello MVC puro, quasi sempre inapplicabile agli schemi enterprise; l’innalzamento del livello di astrazione che provoca spesso il crollo delle prestazioni e altri nefasti effetti collaterali; lo sviluppo a basso livello che tiene le prestazioni e la purezza della scienza ma fa a pugni con la realtà del mercato e dei suoi tempi.

Mi ricordai di tutto questo perché ciò che avevo davanti era la trasposizione pratica di tutte quelle teorie: MVC di semplice applicazione, un elevatissimo livello di astrazione con prestazioni elevate, scalabilità e mantenimento adeguato alle esigenze di enterprise e di mercato.

Installai i tools dalla Apple che, per la cronaca, sono disponibili direttamente nel DVD di installazione fornito con ogni nuovo Mac. Affrontai, con quasi 5 lustri di programmazione alle spalle, la canonica applicazione “Hello World” che però era un qualcosa di full-featured e realmente utilizzabile: un convertitore di valuta. In poche ore mi mangiai letteralmente centinaia di pagine di documentazione e cominciai la mia conoscenza dell’ambiente che ora occupa la maggior parte dei miei impegni professionali.

Fu il mio primo giorno di scuola. E chi se lo dimentica…