L'azienda NON è una scuola

In azienda non si studia. In azienda si deve produrre, l'azienda vive di denaro.
Questa visione, che è comune alla maggior parte delle aziende piccole e medie italiane, produce come risultato che noi oggi usiamo la tecnologia del martinetto, quando le aziende del nord Europa sono alla tecnologia del chip.

E' colpa dei cattivoni nordici che usano l'euro a loro vantaggio se non siamo competivi?
No, è colpa nostra che produciamo roba vecchia, che i cinesi possono copiare senza troppi problemi.

Non sto dicendo che l'azienda debba sostituirsi alla scuola. Perlomeno non alla scuola che conosciamo tutti, "orribile e inutile" (Sant'Agostino)

La scuola addestra all'autorità, ai voti, all'ansia, all'astuzia e alla sudditanza. (I. Sibaldi)

L'azienda deve insegnare in modo fortemente pragmatico cosa offre il mondo moderno e come mettere in relazione le informazioni.

Si pensi a una società di informatica dove non si aggiorna il personale, il quale deve studiare da solo di sera, se vuole e se può. Col tempo le persone che avanzano di carriera per anzianità avranno conoscenze vecchie rispetto ai nuovi assunti e li comanderanno, male e riempiendoli di frustrazioni.

Ora, un software comandato da chi aveva un approccio alla programmazione completamente diverso e vecchio rispetto alle tecnologie attuali, che probabilità ha di usarle nel modo giusto?

Questa è la seconda ragione dietro al fallimento di molti progetti.
Il primo è l'incapacità di capirsi

Quando non basta un'ascia ben affilata

Se avessi a disposizione otto ore per abbattere un albero, ne passerei sei ad affilare l’ascia (A. Lincoln)

Molti anni fa, mi fu offerto di rifare completamente un gestionale interno per un'azienda delle mie parti. Avrei avuto la possibilità di scegliere io gli strumenti o quantomeno di influenzarne pesantemente la scelta.

Ero eccitatissimo all'idea, per una sfida che ero sicuro di centrare, sarebbe stato, pensavo, un successo, finalmente la possibilità di fare qualcosa di grande e di fare il salto di qualità che cercavo.

Per una missione così importante, pensai bene che gli strumenti che avevo usato fino a quel momento non fossero indicati e ancor oggi credo che questo fosse giusto.

Mi informai presso degli amici che lavoravano in città di quale database avessi potuto dotarmi per quell'impresa, senza legarmi a un particolare sistema operativo, perché già allora mi ero avvicinato a Linux e all'open source. Inoltre avevo già studiato i primi rudimenti di Java e di programmazione a oggetti e mi sentivo quasi pronto.

Mi fu consigliato DB2 UDB versione 5 di IBM. Come IDE pensai a Jbuilder 3 Enterprise dell'allora Borland. Avevo a disposizione il budget e degli strumenti di classe enterprise, tutto ciò che avevo chiesto l'avevo ottenuto.

Fu una catastrofe.

Una lezione che imparai col tempo è che una lenta evoluzione è sempre preferibile a una sanguinosa rivoluzione e che quando è proprio necessario buttare via uno strumento intero, si tratta di una situazione veramente grave per chi ha fatto le scelte precedenti. Spesso poi chi fa la nuova versione si trova nel bivio se portare avanti anche i bug o quantomeno i comportamenti sbagliati del programma precedente o se cambiare strada, anziché fare "semplicemente" un porting come previsto.

JBuilder 3 era una cozzaglia di bug, indegno del nome dell'azienda che lo aveva creato e che  aveva una forte tradizione negli ambienti di sviluppo. Le versioni successive erano migliori, ma chi era rimasto scottato da quell'esperienza aveva probabilmente messo una croce sul nome Borland, che dopo pochi anni, guarda caso, cedette gli strumenti di sviluppo ad altri.

Il mio errore? Non averlo provato a sufficienza senza dubbio fu uno sbaglio di inesperienza, ma l'errore più grave fu non chiedere prima al cliente, con una demo magari, se i controlli presenti nell'IDE e completamente proprietari di Borland, avevano un comportamento accettabile per lui e cos'altro avrebbe desiderato.

Fu un'errore che mi costrinse in corso d'opera a cambiare completamente il framework, per SWING. Chiunque abbia sviluppato con SWING sa di cosa parlo...

DB2 era il database di una multinazionale che aveva fatto la sua fortuna sui progetti di gestione dei dati. Aveva funzionalità avanzatissime quali la possibilità di gestire le dimensioni dei pool di pagine del disco, ripartizione delle tabelle, gestiva query lunghe diverse pagine senza problemi, gestiva partizioni sul disco proprietarie saltando il sistema operativo E NON PERMETTEVA DI CANCELLARE UNA COLONNA.
Mi sembrava incredibile, ma bisognava esportare i dati, togliere le integrità referenziali, cancellare la tabella e reimportare i dati senza la colonna, poi ricreare le integrità ecc...
Il cliente era tra il furibondo e lo scoraggiato. Io non riuscivo a darmi una spiegazione ed ero mortificato. Seppi poi che la versione per AIX (io usavo quella per windows NT) non soffriva di questo problema. Una mossa "commerciale" di IBM per penalizzare l'uso di proprio prodotti sulle piattaforme concorrenti? Una sorta di castrazione insomma...

Si trattava di uno strumento rigidissimo, sviluppatosi in contesti dove le specifiche sono scritte nel marmo, mentre una piccola impresa invece vive d'agilità.
Aveva anche dei bug sottili, come il fatto che quando si faceva un restore su una macchina diversa con partizioni gestite direttamente, la nuova partizione doveva essere un pelino più grande, altrimenti il restore non funzionava. Inoltre c'erano altri piccoli comportamenti fuori standard con Java che lo rendevano imprevedibile, fino a quando non si sapeva che fare.

Se avessi fatto un programma più piccolo ma completo prima, forse avrei parato molti colpi, ma il problema principale fu che uno strumento così difficile ha senso soltanto per chi ha contratti di supporto e fa corsi o è inserito in una cerchia di consulenti che lo conosce, magari legati al produttore. La mia ignoranza su DB2 la pagai con il dovere risolvere in fretta problemi sul campo e quel progetto mi fece invecchiare presto. Ancora più grave fu il rapporto di fiducia irrimediabilmente incrinato con chi si aspettava che sarebbe stata una passeggiata e aveva pagato profumatamente quegli strumenti.

DB2 era su un livello qualitativo ben superiore all'IDE che avevo scelto, ma in quell'ambiente e con la mia inesperienza, non era proponibile.
L'aggiunta di problemi con gli strumenti è una vera condanna per un progetto, perché oltre ad avere tempi lunghi, agli occhi dei clienti la colpa ricade sulle nostre capacità.

La paura, madre di ogni freno, fa si che molti scelgano di usare strumenti vecchissimi (si vede ancora in giro del vecchio Visual Basic 6) con la conseguenza che dopo un po'... il nostro software non gira più sui nuovi sistemi... miracoli del consumismo tecnologico.

Soltanto una perfetta padronanza degli strumenti assicura di potersi concentrare sulle esigenze (e sulle convinzioni) dei clienti, i quali prima di tutto devono potersi fidare di noi.

Credo che oggi non rifarei gli stessi errori. (!)

Insicurezza e senso pratico

Tempo fa feci notare a un programmatore freelance, che avrei preferito che sviluppassimo il database usando chiavi esterne con campi singoli interi, perché erano più comodi.
Il tipo trasalì. Diventò tutto rosso e mi rispose che TUTTI USANO LE CHIAVI MULTIPLE.
Sbagliando, lo lasciai fare.
Tempo fa si usavano le chiavi multiple, perché c'era scritto sul libro, perché lo spazio sui dischi era costoso e si risparmiava un campo in più, oppure il db non offriva le sequenze o contatori, quasi indispensabili quando si usa una chiave singola, oppure per motivi di fede in qualcosa che avevano sempre visto fare.

Onestamente, quando si affrontano problemi come la sincronizzazione dei dati su altre macchine, l'approccio tradizionale ha i suoi vantaggi e le sequence/campi contatore/campi identità diventano un problema.

In quell'applicazione le chiavi multiple erano soltanto una complicazione inutile.
Quel collega si sentiva protetto dalle abitudini. Da ciò che aveva sempre visto fare. Era insomma diventato schiavo della sua insicurezza, che placava ricorrendo alle stesse soluzioni.

In un'altra occasione mi trovai a discutere con due programmatori esperti, uno sosteneva che Hibernate fosse la soluzione ai tempi di sviluppo troppo alti che avevano afflitto il loro progetto, l'altro guardava sospirando la semplicità delle procedure Oracle. E' la vecchia diatriba tra se sia meglio tenere la logica nel middleware a oggetti o nelle stored procedure. Non ho mai sentito loro pronunciare le parole"dipende dal problema che si vuole risolvere".

I due erano degli eccellenti tecnici, ma avevano perso di vista che quello che facciamo è risolvere problemi. Fare progetti usando una tecnica sola e imporre quella come se fosse la via illuminata verso il successo è come pretendere di smontare un'automobile usando una sola chiave inglese.
Anche se in teoria forse è fattibile, qualsiasi meccanico si metterebbe a ridere di fronte a una simile proposta e probabilmente prenderebbe per matto chi si accapigliasse per sostenere questa tesi.

Per quanto mi riguarda, posso dire che io mi trovo molto più a mio agio a usare gli oggetti nel middleware, posto che questo non comporti la generazione inutile di migliaia di oggetti in memoria, però spesso ho risolto problemi di performance sfruttando il database, visto che spesso oggi le soluzioni dentro al database sono fatte in linguaggi portabili tra database diversi e sistemi operativi diversi.

Mi sembra un dato di fatto che il database debba essere sempre coerente e che quindi le regole di validità sui dati e l'integrità referenziale debba esserci, anche quando si usa prevalentemente il middleware, questo perché in futuro altre applicazioni potrebbero accedere al db e non vedrei il senso di moltiplicare le regole, replicandole nei vari strati.
Capisco meno magari chi si rifiuta di fare una semplice query dinamica per paura che sia lenta, dal momento che la preparazione del piano di esecuzione oggi spesso è in cache.

Io personalmente la vedo così: le query dinamiche hanno senso in contesti dinamici, quindi quando la query si costruisce dinamicamente cambiando volta per volta quali campi o filtri sono coinvolti. Credo che rinnegare un database relazionale maturo e magari costoso non abbia senso, in quanto non ha senso spendere fino al punto di rischiare un fallimento per risolvere problemi che non si hanno. Questo può sembrare un controsenso perché a tutti viene insegnato di prepararsi (per non dire addirittura preoccuparsi, altro errore) per il futuro.
Eppure viviamo nel presente. Sembra strano ma roviniamo il presente che è certo per il futuro che è incerto.
Io stesso ho fatto procedure enormi con strati che ripetevano le stesse cose per ciascun strato: un controllo javascript sulla pagina html, poi lo stesso controllo nel middleware, poi altri controlli nel db. Questo si traduce in COSTO. Un costo per una qualità non sempre richiesta.

Credo che non tutte le applicazioni abbiano bisogno di essere strutturate come il sistema informativo di una banca, così come non tutte le persone sono disponibili a pagare auto di lusso pluriaccessoriate e sono felici di usare delle utilitarie a un costo che è una frazione. Questo non vuol dire non fare lavori di qualità, vuol dire fare lavori nei costi che chi paga è disponibile ad accettare.

Chi non capisce questo e segue la strada maestra indicata nei forum e nei libri, per sentirsi sicuro di avere fatto il lavoro a regola d'arte e tutelarsi dalle critiche future dei colleghi, dalle contestazioni dei clienti e dalle future richieste di modifiche stravolgenti, è soltanto un insicuro, perché la gente è libera di criticare in base al pensiero del momento, perché il cliente si accorge di cosa vuole quando in effetti mette le mani sulla programma, perché cosa ci accadrà è stimabile, ma imprevedibile. E' la vita.

Programmazione Orientata agli Stipendi

Anni fa due miei giovani colleghi mi dissero che EJB era nato per fare un modello a oggetti, partendo da un modello relazionale.
Già allora la loro convinzione mi lasciava perplesso.
Credo che EJB sia nato per favorire il passaggio delle procedure COBOL verso Java. Banche e assicurazioni usavano COBOL e erano i clienti pronti a pagare. L'ecosistema Java è stato guidato dal business, non da chi scrive pattern.
EJB non è OOP, non perché chi lo ha scritto non fosse abbastanza bravo, ma perché è stato fatto per essere orientato ai servizi, come richiesto dai clienti pronti a pagare i ricchi middleware EJB.
Non lavoriamo in un mondo ideale sul piano tecnico scientifico, lavoriamo perché qualcuno ci paga o speriamo proprio che lo faccia.