Tecnologia e Moda
Oggi mi sono svegliato presto, ma talmente presto, ma proprio talmente tanto presto ... che finalmente riesco a trovare il tempo di scrivere un bel post chilometrico.
Vi metto alla prova, cari lettori, per vedere se anche questa volta riuscite a resistere alla tentazione di saltare oltre e continuate a leggere sino al punto finale. Se avete seguito almeno un po' il mio neonato blog, sapete chi è Pino. Per chi non lo sa, una breve presentazione.
Pino è un personaggio che non esiste, neanche nel mondo dell'invenzione. Pino è la rappresentazione dei guai, degli sbagli, dei problemi e delle assurdità che gravitano intorno al programmatore moderno. A volte commette errori per inesperienza e superficialità, altre li subisce per mancanza di polso e di ruolo.
A volte Pino è un navigato programmatore, talmente legato alle abitudini da non riuscire a vedere le cose da angoli differenti.
Altre è un giovane, entusiasta e ancora troppo inesperto per capire che non sempre, anzi quasi mai, le scelte vengono fatte per ragioni tecniche. L'ignoto non lo spaventa, anzi lo stimola ad imparare. L'aggiornamento continuo è il succo delle sue capacità. Come in questo caso. Leggete ...
"Pino, stopomeriggio riunione con quelli di là. C'è da risolvere quella questione di ieri."
La questione, per inciso, riguardava l'architettura di alcuni componenti del middle-tier.
Il prodotto, ormai in produzione da alcuni anni, aveva sofferto di una progettazione carente, ed alcune problematiche stavano venendo a galla alle prime necessità di scalare. E di cosa ci si stupisce ? Non è che ci voglia tanto ad implementare un application server che soddisfa 100 richieste all'ora. La scelta di una tecnologia rispetto ad un altra non mostra quasi mai i propri limiti in situazioni di basso carico. I problemi, quindi, sorgono di solito ben dopo il rilascio dell'applicativo, quando il cliente inizia ad accorgersi (noi non abbiamo mica fatto stress test, figuriamoci) che le cose funzionano un po' lentine.
Insomma, il software che era stato sviluppato non reggeva. Non era lento, magari fosse stato solo lento, ma proprio non reggeva. Macchina in hang e via dicendo.
Pino era entrato nel progetto da alcuni mesi, e a dire la verità stava seguendo altri aspetti (customizzazione di interfacce grafiche, quelle sì che sono fondamentali !). Ma le riunioni coinvolgevano tutti. E quindi coinvolgevano anche Pino.
Il commerciale, seduto in fondo al tavolo, presentò in breve le problematiche sollevate dal cliente. E chiese lumi.
Il PM, che già conosceva la questione, era visibilmente preoccupato, e a ragione. L'architettura, così com'era, non poteva essere espansa. andava riprogettata. E non era cosa da due settimane, potete ben immaginare.
Fatto sta che andava fatto. E iniziò ad esporre le problematiche sollevate da un punto di vista più tecnico. Insomma, era chiaro, e tutti se ne rendevano conto: rasare via, ricostruire, ritestare, sostituire, e incrociamo le dita.
Ma come farlo ? In quanto tempo ? Per l'application server attualmente in produzione erano stati impiegati 4 anni uomo tra analisi, sviluppo e test. Il cliente, giustamente, premeva, e il budget (quindi il tempo) a disposizione era a dir tanto di 6 mesi uomo. E visto che 6 mesi uomo non vuol dire 1 mese con 6 uomini, si ipotizzò un periodo di 3 mesi, con 3 persone dedicate a tempo pieno. 3 x 3 fa nove, ma dentro c'erano imprevisti e così via. Si andava in perdita, ma si manteneva il cliente.
Impossibile stare nei tempi.
Lo so che ve lo state chiedendo, e vi rispondo subito. Il middle tier era un aggregato mostruoso di componenti COM. Sviluppati in C++ con ATL, e piuttosto complessi.
Pino non lavorava ancora lì, ma gli avevano raccontato, con un senso di soddisfazione per aver domato un mostro a 12 teste, che dopo settimane di nebbia erano riusciti a capire e implementare un'infrastruttura DCOM a prova di bomba. "A prova di bomba mica tanto", pensava Pino fra sè e sè, "dato che al primo minimo aumento di carico stava andando tutto a catafascio". Tienitele per te queste considerazioni, caro il mio Pino, che sei l'ultimo arrivato. E così fece.
Fatto sta che questa roba si doveva ristrutturare, e pesantemente anche.
Iniziarono le prime proposte.
E, potete bene immaginarvelo, una parola su due era "COM", "DCOM", "COM", "DCOM", "COM", "Componente COM" (giusto per variare un po' sul tema). I più all'avanguardia iniziavano a snocciolare le direttive dell' architettura DNA, tanto che tra un "COM" e l'altro entrò pallidamente anche qualche "MTS" e, guarda un po', un "COM+" buttato lì quasi per caso.
Pino seguiva con attenzione. "Caspita come siamo avanti !".
Ah, tra parentesi, è il 2004, cioè oggi. "Chissà se sanno che qualche hanno fa hanno rilasciato quella strana roba che risponde al nome di .NET ?", si chiedeva Pino.
E mentre qualche collega dalla pluriennale esperienza illustrava con aria da Dio in terra le potenzialità di COM per un'architettura veramente distribuita e scalabile, i pensieri di Pino iniziavano a vagare.
"In base alle ultime esperienze con DCOM", sentiva in sottofondo, "e grazie al modello ADO, possiamo implementare un data access layer bla bla bla ...", e intanto Pino pensava ad ADO.NET.
"... che parla tramite protocollo RPC con un singleton contenuto nel middle tier bla bla bla ....", e intanto Pino pensava a Remoting.
"Inoltre, data l'esperienza massacrante con MFC, un'infrastruttura COM ci permette di sviluppare interfacce grafiche con Visual Basic, così parallelizziamo il lavoro perche quelli di là ....", e intanto Pino pensava a WindowsForms.
"Direi inoltre che conviene rinunicare alla funzionalità di MSMQ, perchè sono scomode da implentare e in fin dei conti ne possiamo anche fare a meno ....", e intanto Pino pensava a quella volta che, dopo aver letto un articolo sul sito dell'MSDN, aveva fatto una provetta con MSMQ.NET, e in un'ora era riuscito a completare un sistema di messaggistica essenziale ma carino.
"E' chiaro che le risorse a disposizione sono troppo poche per un progetto di questa complessità. Serviranno due esperti di questo, due di quest'altro, tre di quest'altro ancora, tutti con una solida conoscenza di COM e programmazione multithreading, poi due o tre sviluppatori per le interfacce grafiche, il gruppo di test ...."
Pino era meditabondo. Alla fine era lì in riunione senza la possibilità, o la convenienza, mettetela come volete, di dire la sua e proporre qualcosa di ... migliore. Gli sembrava che nessuno avessa tenuto in conto l'idea di utilizzare altre tecnologie che non quelle, per così, dire, vecchie e consolidate. Che ci fossero ragioni di competenze non lo metteva in dubbio, e anche i tempi stretti facevano la loro parte. Ma almeno pensarci si poteva, o no ?
Insomma, gli sembrava che più che una ristrutturazione fosse un reimpasto, un'occasione per spostare due componenti da una parte all'altra e nel mentre correggere qualche baco vagante e mai ben identificato. E chiamala ristrutturazione, quella.
Così dalla bocca di Pino uscirono, a sua insaputa e nel bel mezzo di un discorso del PM, tre parole lapidarie: "Perchè non .NET ?".
Pino ebbe appena il tempo di accorgersi di aver fatto la sua cavolata quotidiana che il PM smise di parlare, ei girò verso di lui e lo fulminò con uno sguardo. Tutti zitti. Non si sapeva se aspettavano che Pino continuasse un discorso che in realtà non avrebbe voluto iniziare, o che il PM gli tirasse un posacenere dritto fra gli occhi.
In realtà non successe nè l'una nè l'altra cosa. Prese, invece, parola un altro programmatore "anziano", il guru del C. Chiamiamolo Guru (nome proprio) per capirci.
Insomma, Guru interruppe sia Pino (e Pino tirò un sospiro di sollievo) che il PM (chiamiamolo PM, nome proprio) e disse:
"Qua se non siamo alla moda non siamo contenti, vero ?"
Silenzio.
"A me già sto COM non convince, si poteva fare un bel socket server che si faceva prima. Comunque va bene, e COM sia. Ma .NET, eh no, non diciamo assurdità !".
Silenzio.
Alcuni avevano la faccia di chi non capiva una mazza e pensava che .NET fosse solo un dominio di primo livello.
Altri erano chiaramente d'accordo con Guru e scuotevano la testa guardando il povero Pino, diventato ormai microscopicamente stretto nelle sue spallucce.
".NET fa schifo, è una moda passeggera. Cos'ha in più ? Moda, solo una moda. O un modo di vendere qualcosa di cui non c'è bisogno".
Qualche rumorino, qualche brusio. Facce consenzienti, sguardi di fuoco per il povero Pino, che stava lentamente sparendo sotto il tavolo.
"Qui se non siamo alla moda non siamo contenti, non è vero ? Andiamo sempre a cercare le soluzioni all'ultimo grido, così ci possiamo riempire la bocca con i paroloni. Web Services, ma che roba è ?! Figurati se li userà mai qualcuno. .NET Framework, ma che bel nome ! Ma va là, non perdiamo tempo con ste s*******e, che qui si deve lavorare, mica giocare."
Ci mancava che partisse un applauso e Pino si sarebbe ridotto a dimensioni molecolari.
Invece ci si mise anche il commerciale, che non conosceva la differenza tra una stringa C e una stringa delle scarpe, ma al sentir dire che bisogna lavorare, e non giocare, colse la palla al balzo.
"Ha ragione Guru, dannazione. Mettiamoci in testa che sta roba la dobbiamo vendere e far funzionare, mica ci dobbiamo fare i fiocchettini e firmarla D&G !"
"Poi tu cosa parli, Pino, che tanto più che i test non potrai fare ?"
Allora Pino, praticamente in catalessi, si lasciò scappare la seconda infelice uscita della riunione: "Ma magari si riescono anche a ridurre i tempi ..."
Guru non lo lasciò finire.
"Ma tu sei abelinato veramente !" (nda: abelinato è genovese, significa scemo, idiota, cretino, imbecille, stupido, giusto per rimanere in un ambito relativamente poco volgare).
"Ma se abbiamo migliaia di righe di codice da copiare, e funzionano ! In due giorni facciamo un componente che ascolta su una porta TCP e risponde, ci manca solo il protocollo, ma tutto il plumbing è già fatto. Te lo incolli nel codice, e hai fatto. Ma a te ti paga la Microsoft per dire ste cose ? Non mi vorrai mica dire che ci si mette di meno, dai. Eh, ragazzo mio ....", concluse Guru, dall'alto della sua pluriennale esperienza di programmatore in C, " ... ne hai ancora di cose da imparare."
Vero.
Ne aveva di cose da imparare, il nostro sconsolato giovane programmatore.
Primo. Che le scelte spesso non si basano su considerazioni tecniche, ma solo su questioni di opportunità: competenze del team di lavoro, riciclo di roba esistente, tempi, tempi e soprattutto tempi.
Secondo. Che cambiare e imparare qualcosa di nuovo piace a chi è entusiasta del proprio lavoro, ma è un incubo da ricacciare indietro per chi del proprio lavoro ha fatto routine.
Terzo. Che le tecnologie più recenti sono, prima di tutto, una moda. Non importa se poi l'abito è comodo, resistente, elegante, duraturo. Se è di moda è negativo. Perchè noi siamo programmatori, e la moda non la seguiamo mica.
Quarto, ed ultimo. Che prima di parlare ci si deve pensare dieci volte. Perchè le prime nove si valutano le conseguenze della propria frase come se l'avessimo ascoltata noi, e solo la decima ci si rende conto che la cosa più sacrosanta del mondo può essere confutata (a torto, ovviamente), e che chi ci critica può avere l'appoggio di tutti, anche di chi decide.
Triste, ma vero.