Com’è possibile che un soggetto completamente a digiuno in materia di software sia capace di dirigere un progetto senza che nessuno se ne accorga? Non dovrebbe essere evidente la sua incompetenza? Ed il progetto, non dovrebbe fallire clamorosamente? Eppure, questi loschi figuri conservano il loro posto di lavoro per anni (normalmente fino a quando l’azienda fallisce). La chiave di questo mistero risiede nel progetto bicicletta.

A grandi linee, le fasi di un progetto bicicletta sono: Analisi dei requisiti, progettazione, implementazione, fase di prova, consegna, revisione. Durante la fase d’analisi dei requisiti, il cliente dà informazioni sulle sue richieste, durante la fase di progettazione si da forma al prodotto, durante la fase d’implementazione si programma, durante la fase di prova si verifica che tutto sia andato per il meglio.

Le prime quattro fasi possono sembrare le più importanti, ma in un progetto bicicletta, si rivelano del tutto trascurabili. Viene lasciato invece tutto alla fase di revisione (quella che di solito ci tocca).

In queste prime fasi il nostro amico manager non lavora (ricordiamo infatti che semplicemente non ne è capace), si limita a trascinare i piedi. Fino alla fase di consegna non c’è nulla di cui preoccuparsi, basta fare il finto tonto. Ma certo, bisogna avere poi qualcosa di tangibile, qualcosa da far vedere alla direzione durante le riunioni. Da dove lo si recupera? Basta scaricarlo da internet o comprarlo. Poniamo che il cliente abbia bisogno di un sistema di workflow, accessibile via internet e che sia scalabile. Bene, si va allora su un motore di ricerca e si digita “cheap web-based workflow system java source code download”. Si naviga un pó, si cerca un prodotto colorato in modo futuristico, si estrae la carta di credito, e voilà. Il progetto bicicletta ha preso forma.

Dopodichè, il nostro amico manager sceglie una squadra di sviluppo per le fasi due, tre e quattro. L’esperienza gli ha insegnato che per progetti bicicletta bisogna scegliere sviluppatori tra i più idioti meglio, affinché non si rendano conto del fregatura (qui si segui il principio del “re nudo”).

Si comincia a sospettare che nelle scrivanie vicine si sta eseguendo un progetto bicicletta quando il team di sviluppo-merdoso si fa dei bei pompini. Si scambiano delle perle pompose, del tipo: “i canali di intercambio d’informazione sono molto chiari”, “il fattore usability è determinante nel disegno dei javabeans”, “ho incrementato i parametri del costruttore, ti mando il file punto class via mail”, o ” questo JSP ha tremila righe perché ho applicato un pattern FACADE di accesso concentrato”.

Due mesi dopo arriviamo alla fase di prova. Ovviamente il prodotto è una merda. Però le prove sono a carico della stessa squadra, e ogni scarrafone è bello a mamma sua. Quindi con la testa ben in alto, si crea un file zip, un manuale d’installazione, e consegna tu, Carletto, che a me mi vien da ridere. Stato del progetto? Consegnato. Venerdì notte. Cenone per il progetto. Applausi, risate, altri pompini. Lunedì arriveranno le sorprese.

Adesso illustriamo la fase di revisione con un esempio grafico:

Il progetto porsche.

Arriva il lunedì e apri la posta. Oggetto: “Problematiche nel progetto Porsche”. T’ingaggiano per “un paio di giorni” per “dare una mano” con “qualche bug”. Riunione tra un quarto d’ora. Entri nella sala riunioni. Lì c’è il nostro amico manager. Ti spiega la storia: il progetto porsche è di importanza vitale per l’azienda. Hanno applicato moderne techiche di disegno e implementazione è sono riusciti a consegnare al cliente un prodotto perfettamente compatibile con i requisiti del cliente: un Porsche decapottabile, sicuro, leggero, veloce, a basso consumo energetico e di basso costo. E’ stato fatto rapidamente e bene. Un successo. Nella fase di revisione sono sorte alcune piccole problematiche che bisogna sistemare.

Bene. Vediamo il prodigio. Entriamo nell’hangar del progetto porsche, e lì c’è la creatura: una bicicletta. Da passeggio. Senza cambi nè niente. Ha un adesivo dietro al sellino con il logo dell’azienda e la parola “PORSCHE”. Nella cesta ha un certificato ISO9000. A questo punto normalmente tu vai in collera e cominci a gridare che vuoi vedere l’amministratore, i soci fondatori, i clienti, gli azionisti, il papa. Desideri veder impiccati tutti i responsabili in pubblica piazza.

In seguito ti portano al ufficio di Risorse Umane, ove tisomministrano la terapia combinata “Ludovico/Stanza101″. La bambola delle R.U., che sovente ha nomi del tipo “Maika” o “Ivon” e si veste con quei tailleur di pantalone nero e tacchi stile puttanone-in-carriera-con-MBA, ti interroga con la sua voce Valium 500:

[Ivon] Signor Fuckowski, quali sono le sue lamentele rispetto al progetto porsche?

[io] MA QUALE PORSCHE?!?!

[Ivon] Il progetto Porsche, uno dei più importanti…

[io] [io] Massì, massì!! Guardi che l’ho imparata bene la filomena! È una bicicletta del cazzo! E io devo farla diventare una Porsche in due giorni, con un cacciavite ed un pennello Cinghiale!!

[Ivon] Signor Fuckowski, è vero che il porsche presenta alcune problematiche, ma….

[io] BICICLETTA!! BICICLETTA!!

[Ivon] Signor Fuckowski, sta attraversando una crisi personale? Dev’esserci un motivo che giustifichi il suo atteggiamento negativo circa il porsche.

[io] No. Sto divinamente. O almeno stavo, fino a quando ho visto la bicicletta.

[Ivon] Stanza 101, signor Fuckowski .

Stanza 101. Sedia con cinghie. Camicia di forza. Loghi dell’azienda. Certificati di qualità. Proiettore XGA. Schermo panoramico che presenta un’enorme bicicletta da passeggio. Lì ti aspetta l’amministratore dell’azienda.

[amministratore] Signor Fuckowski, descriva per cortesia questo porsche.

Mi risparmierò i dettagli della tortura, ma dico solo che c’entrano dissertazioni sull’atteggiamento positivo, l’adesione alla visione dell’azienda, l’auto-motivazione, le scritte in piccolo sul contratto. In sintesi, se non vedi il porsche sei disoccupato.

Dopo il pranzo sei già perfettamente motivato, assistendo a una conference call tra l’azienda, nella persona del manager, e il cliente, nella persona di un consulente con l’abito nero e la cravatta allucinogena, assunto ieri, che guadagna 100 all’ora più le commissioni, e che non ha nessun interesse nel dire “mettetevi la bicicletta dove sapete” e prendere 25 euro per quindici minuti.

[consulente] Bene, vediamo di chiarire le problematiche riguardanti il porsche. La prima cosa che abbiamo notato è che mancano due ruote.

[manager] Sí, ci siamo decisi per il disegno minimalista che si accorda meglio alla nostra visione d’azienda: “pratico, funzionale, ottimo”..

[consulente] Vedo. Ma un porsche di due ruote non si sposa bene con il nostro modello di business. Ci serve con 4 ruote.

[manager] Credo che potremo rifattorizzare il porsche e fare un clone per aggiungere due ruote in più, vero? - stavolta guarda me.

[io] Sí, hahaha!! In cazzeggio!!! Dammi un’ora.

[consulente] Perfetto. Bene, il secondo problema. Non troviamo la capotte.

[manager] Sí. Lo volevi decapottabile, no? Beh, noi abbiamo semplificato molto l’usabilità eliminando la capotte.

[consulente] bene ma, non solo volevamo toglierla all’occorrenza, ma vorremmo anche poterla rimettere.

[manager] Ah. Questo non era specificato nei requisiti iniziali, quindi lo consideremo come funzionalità extra e quindi la fattureremo a parte. Che impatto ha questo nuovo requisito nel sistema? - mi guarda di nuovo.

[io] Fortunatamente le interfacce sono molto pulite, quindi possiamo modificare lo strato esterno senza intaccare il kernel, hahahha.

[consulente] Perfetto. Un’altra cosa, dove sono la serratura e la chiave? chiunque potrebbe rubarci il porsche.

[manager] Ci siamo decisi per un modello multiutente per l’implementazione iniziale, pero potremo aggiungere un modulo di sicurezza al sistema, no?

[io] Sìììì!! Precisamente ho qui un modulo di encriptazione SSL per porsche!!

[consulente] Ottimo. Solo due problemini ancora. Viene richiesto troppo sforzo all’utente per utilizzare il sistema. Potreste sostituire i pedali con un motore?

[manager] Inizialmente volevamo che l’utente avesse la massima libertà d’azione, e per questo motivo abbiamo scelto un modello di utente pesante.

[consulente] Va bene, ma troviamo che la quantità di lavoro lasciata all’utente sia eccessiva.

[manager] Possiamo arrivare a un compromesso ragionevole tra la libertà dell’utente e l’automatizzazione dei processi, non è vero?

[io] Indubbiamente. Sostituiremo il motore a giri assistito da pedali per uno compatibile assistito da pistoni. Forse bisognerà aggiungere un modulo di stoccaggio esterno per carburante, ma lo potremo sempre mettere nella cesta, hahaha.

[consulente] Sono con te al cento per cento. L’ultima cosa: il sistema non ha superato le prove di rendimento. Tra i requisiti figura che il sistema deve raggiungere i duecento all’ora.

[manager] Il rendimento è sempre variabile, a seconda della piattaforma. Le specificazioni di questo sistema sono “autostrada di ghiaccio con 70% di pendenza discendente”.

[consulente] Bene, verificherò quale piattaforma stiamo utilizzando. Ma credo che avremo bisogno di più velocità.

[manager] Possiamo sempre perfezionare il kernel, non è vero?

[io] Vero com’è vero che mi chiamo Fuckowski

[consulente] Molto bene signori. E’ stato un piacere.

Tre del mattino. Un thermos di caffé. Un secchio di vernice, un cacciavite. E una bicic… un porsche.

Traducción:
Sol Kawage [email][web]

Fabrizio Ferri Benedetti [email][web]

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.

Traducción:
Sol Kawage [email][web]

Fabrizio Ferri Benedetti [email][web]