Sentire Puttanate
Qual’è la parte più difficile del lavoro di uno sviluppatore di software? L’architettura, l’analisi funzionale, tecnica, la programmazione? No. L’aspetto veramente duro è dover sentire puttanate.
Ricevi una mail dall’IT manager, quell’individuo che secondo il suo curriculum ha “collaborato nella concettualizzazione di progetti di convergenza” ed è stato ” direttore di espansione di strategie di quarta generazione”, e il cui lavoro consiste in inoltrare le mail dei clienti ai tecnici e viceversa, e leggere cose su internet per avere qualcosa da dire (con Google e un paio di filtri sul client di posta, l’azienda risparmierebbe 80.000 euro l’anno). La mail ha come oggetto “Brainstorming”. Ed è lì che sei fottuto.
Il “brainstorming” o “tempesta di cervelli” è (o dovrebbe essere) la riunione in cui tutti portano il proprio talento o esperienza per trovare soluzioni ottimali ai problemi. La realtà è che nella tempesta di cervelli, il manager di solito mette la tempesta e tu metti il cervello. E nella tempesta, come nel mare mosso, il guadagno è per i pescatori. Tu pensi, abbozzi, trovi soluzioni, che un motivo c’era se volevi diventare ingegnere. Lui si segna il gol, che un motivo c’era se ha fatto un master in “strategy business JabbaDabba”.
Così arrivi in sala riunioni con la con la puzza al naso. Lì c’è lui, con il portatile, la tazza di caffé, e un mucchio di carte (di solito stampe delle mail dei clienti con le loro richieste, ovvero, il problema in sé, e neanche un foglio in più che dica che ha impiegato del tempo a trovare soluzioni a niente).
Sai già a cosa ti esponi. Ti chiederanno il ben noto “e adesso che faccio” ma senza dare nell’occhio. Di soppiatto. Come se tu fossi un imbecille. Ma non finisce lì: sarai la cavia sulla quale testare gli ultimi discorsetti sentiti nei forum o nei “cookbooks”, tu li accetterai o li rifiuterai, li correggerai, ed infine aiuterai il profilarsi di quella superficiale saggezza, quell’arte di “fare finta di avere ragione” (vedasi Schopenhauer) con la quale questi individui giustificano buste paga esorbitanti davanti alla direzione (che normalmente sa solo rendere pan per focaccia).
Così, te la prendi sul personale. Bisogna mettere in chiaro che
A) il pane è il pane, e una focaccia è una focaccia, vale a dire, un’idea è un’idea e una stronzata è una stronzata, e tu sai distinguerle bene
B) Si può fare della demagogia discorrendo sul sesso degli angeli o sull’arte astratta, ma non sul software
C) non si impara su un forum in un’ora quello che ti è costato diversi anni di università, altrettanti di lavoro, molto caffé e molti straordinari
D) un imbecille con un libro non è un ingegnere
E) Un master, una cravatta e un palmare fanno pendant, ma non donano buon senso a chi non ce l’ha.
Insomma, che cominci il circo. Mettiti le cinture. Aggrapati con forza ai tuoi principi, perché stanno per applicarti la cura Ludovico (vedasi Arancia Meccanica). Ti immobilizzeranno su una sedia, ti drogheranno, ti terranno le palpebre aperte con dei supporti, e ti costringeranno alla visione di due ore di Power Point. Ti sottoporranno a spaventose torture psicologiche con il duplice obiettivo di ottenere informazioni e contemporaneamente convincerti di realtà alternative.
A seguire riporto frammenti reali (do la mia parola d’onore) di riunioni con il mio attuale IT manager circa diversi progetti Java e VB nei quali “abbiamo” lavorato.
Perla 1: Hibernate
[manager] Cosa utilizziamo per i dati?
[io] Usiamo Hibernate
[manager] E’ meglio usare Entity Beans
[io] Perché?
[manager] Entity Beans sono compatibili con J2EE, e inoltre stanno in un pool, Hibernate non ha pool e quindi va più lento.
Quando stavo per spiegargli la stronzata che aveva detto, erano così tante le idee che mi si sono accumulate in testa di colpo che mi era subentrato uno stato di shock, e dovetti procacciare un bicchere d’acqua. Credo che questa sia una specifica tecnica di argomentazione, che dovrebbe chiamarsi “è tanto grande la cazzata che non si può ribattere”. Se qualcuno ti dice “due più due fa cinque”, si può argomentare che fa quattro. Se qualcuno dice che “due più due fa una costellazione vicina a Alfa-Centauri”, si può solo rispondere “ma di che minchia parli?”; aloro volte ti possono dire “Si vede proprio che non hai fatto un Master JabbaDabba”
Perla 2: Easy Upgrade
Eravamo in riunione con dei clienti americani ai quali avevamo venduto un programma (tanto per chiamare in qualche modo quella monnezza programmato da un “senior con 10 anni d’esperienza” e che io ho dovuto mantenere successivamente). Il processo d’installazione consisteva in decomprimere un file zip nel disco fisso e poi eseguire un setup.exe (non funzionava installando direttamente dal CD). Il file zip includeva le cartelle della base dati. Ogni volta che gli passavamo la nuova versione, se non volevano perdere i dati precedenti, dovevano rinominare la base dati vecchia, installare la versione nuova completa (bisognava per forza installare la base dati nuova, perché parte della logica e delle risorse del programma risiedevano lì - non chiedetemi perché, chiedetelo al “senior”-), e poi importare le tabelle con degli script. (ci ho messo una settimana affinché il tecnico della filiale giapponese lo facesse correttamente).
[cliente] Potreste semplificare il processo d’installazione?
[manager] Si, produrremo un processo d’installazione che all’inizio faccia un diff come in Source Safe ed installi solo ciò che si è modificato o aggiunto
Sono stato lì un attimo a dubitare se quest’uomo sapesse che il codice sorgente vada compilato.
Perla 3: Interfacce magiche
In questa riunione mi chiedeva di disegnare un portale (una specie di carrello della spesa con i servizi dell’azienda), e per risparmiare tempo voleva che lo facessi pensando alle necessità e alle specifiche di un solo cliente, il primo che eravamo riusciti a inchiappetare.
[io] Ma se faccio il portale specificamente per un cliente, non potremo riutilizzare il codice. Vuoi che disegni la logica in forma generica, anche se mi porterà via un pò più di tempo?
[manager] No, non abbiamo tempo.
[yo] Allora quando avremo un secondo cliente, dovremo fargli un altro portale diverso.
[manager] No, riutilizzeremo quello che faremo ora
[io] Allora, lo faccio generico, no? Più tempo….
[manager] No, fallo specifico, ma tenendo ben presente che lo riutilizzeremo
[io] Scusa, spiegami con quale tecnica creo velocemente qualcosa di specifico ma riutilizzabile
[manager] Unicamente tiene pulite le interfacce.
Mi son chiesto se esisteva un “Omino Bianco Design Pattern”. Poi ho cercato di farmi spiegare come si fa a programmare una logica specifica che implementi un’interfaccia valida per tutti, e ammesso e non concesso che ci riuscissimo (qualcosa come definire uno standard tipo JDBC e creare diversi drivers), alla fine avremmo riutilizzato solo l’interfaccia (mezz’ora di lavoro?) e quindi eravamo al punto di prima. La sua risposta è impossibile da riprodurre.
Perla 4: Override autoincremental keys
Questa volta dovevamo disegnare una logica di business transazionale che operava su due sistemi diversi, un workflow e un software di preventivi (entrambi con il proprio API). Bisognava mettere in relazione entrambi per far sì che quando un cliente chiedeva un preventivo, si creasse un compito nuovo nel workflow e un preventivo nuovo a lui associato.
[io] Dobbiamo creare un metodo che automaticamente inizi una transazione, aggiunga un compito al workflow, conservi l’ID, poi aggiunga un preventivo, conservi l’ID, registri la relazione tra i due ID e faccia “commit”
[manager] Per risparmiare tempo facciamo sì che l’ID del compito e l’ID del preventivo siano sempre uguali, così non dobbiamo metterli in relazione. (QUesta da sola potrebbe essere la Perla 4, ma non è finita)
[io] Guarda, anche se potessimo specificare noi le chiavi, dovremmo sapere quali ID abbiamo usato per generare i nuovi, e ciò sarebbe peggio che mettere in relazione due ID. Inoltre, le chiavi sono campi autoincrementali sia nel workflow sia nel sistema dei preventivi, per cui non possiamo specificarle noi a nostro piacimento.
[manager] Ma c’è un meccanismo negli Entity Beans che permette di specificare le key dei registri inseriti.
Dopo essermi ripreso dallo shock, mi sono fatto un trip col meccanismo:
EntityBean: InsertTaskWithKey(55)
DataBase:SQLException:KeyViolation
EntityBean:CazzoTiHoDettoDiInsertTaskWithKey(55)
DataBase: e va bene!
Perla 5 - Java Word Parser
A volte gli utenti del portale di servizi suddetto caricano file formato Word affinché l’azienda (che si occupa di ricerca di contenuti) li traduca a diverse lingue. Bisogna stimare il costo della traduzione automaticamente, per dare al cliente un preventivo immediato. Bisogna unicamente contare il numero di parole nel documento e moltiplicarle per il prezzo per parola stabilito.
[manager] Come possiamo rendere automatici i preventivi?
[io] Devo cercare una libreria Java per file doc, integrarla nel portale, e creare una funzione che mi renda il numero di parole.
[manager] No, sai che ti dico? facciamo una cosa ancora più veloce. Possiamo riutilizzare le macro di Word che hanno nella sezione di Prova.
Facile. Abbiamo bisogno di un semplice “Enterprise Word Server” che possa girare su Solaris, che possa essere installato in cluster, e al quale si possa accedere via RMI.
Spero che grazie a questi esempi il mondo capisca la mia sofferenza. Alla prossima.
trackbacks
