Parlo ogni giorno con i clienti di Iaas e PaaS e di come aiutarli a traghettarli dall’IT tradizionale al cloud computing ma spesso mi trovo di fronte a situazioni decisamente imbarazzanti sullo stato delle loro risorse (umane) che si occupano di sviluppo software e i progetti falliscono ancora prima di partire.
Lo sviluppatore vecchia maniera
Molti sviluppatori hanno iniziato a produrre codice quando ancora non si parlava neanche di sviluppo ad oggetti, alcuni hanno iniziato con il Cobol o con il Basic… e magari ancora usano strumenti di questo genere per portare avanti il proprio lavoro.
Intendiamoci, non ho nulla contro queste persone, ma un conto è se stanno ancora mantenendo del software su un Mainframe o su un AS/400 (ora iSeries), un altro è se stanno cercando di lavorare con applicazioni web o cloud.
Ecco, nel secondo caso non vanno bene sia il cobol che il basic ma non vanno bene neanche le tecniche di programmazione tradizionale o il codice scritto particolarmente male.
Oggetti, questi sconosciuti
La programmazione a oggetti? Bella, ma spesso applicata nel peggiore dei modi. Codice scritto con tecniche da programmazione procedurale, garbage collection lasciato al caso (nel migliore dei casi), ecc., ecc.
Negli anni passati, si sono viste cose pessime e codice scritto in modo non proprio appropriato ma ci si è passati sopra perché bastava comprare hardware più potente: il prezzo dell’hardware era in calo e ci si poteva permettere di sopperire con la forza bruta alla mancanza di intelligenza. Un altro bel danno lo hanno fatto i tool di sviluppo rapido che, spesso, hanno immesso molte funzioni standard e poco ottimizzate creando codice sempre più pesante e poco gestibile.
Non posso evitare anche di menzionare i danni fatti dagli sviluppatori autodidatti che hanno iniziato a fare il copia e incolla (e relativi smanettamenti) di codice PHP (ma anche javascript e altri) sul proprio web server, per convincersi poi di essere diventati sviluppatori (questi sono fra i peggiori).
Alla fine questo approccio ha iniziato a mostrare i suoi limiti ma in pochi hanno avuto il coraggio, i soldi o le capacità di riscrivere le applicazioni.
Il disastro viene con il cloud
La scalabilità veritcale non esiste, le applicazioni devono essere disegnate (o convertite) per ragionare con architetture che spesso sono stateless e dove non sono previsti meccanismi per gestire il fail (cluster HA). Infine, ultimo ma non ultimo, si paga per quello che si consuma!
Quindi, per godere dei vantaggi del cloud è necessario conoscere a fondo l’architettura dei diversi cloud provider e delle architetture cloud in genere… cosa che gli sviluppatori tradizionali spesso ignorano!
La mancanza di cultura
Di cultura se ne trova poca, crearla o condividerla costa… gli imprenditori e le software house si guardano bene dall’investire (spesso i gestionali sono stati sviluppati negli anni 80 e 90 e ora chi aveva fatto il lavoro è vecchio e guarda più a monetizzare il più possibile e puntare alla pensione piuttosto che fare nuovi investimenti (magari investimenti sui giovani)!
E’ vero c’è internet, quindi il giovane sviluppatore potrebbe anche “autoformarsi” ma, da un lato capisco sia comunque difficile, dall’altro ha un costo.
Inoltre, e questo è un dato di fatto, è inutile pensare di investire personalmente per diventare uno vero “sviluppatore per il cloud” quando poi non si ha la possibilità di mettere a disposizione il proprio sapere ed essere valorizzati per per le proprie capacità: l’entusiasmo si spegne presto se non lo sia alimenta con sfide e successi!
Nota finale
ok, ho lanciato la provocazione e ci tengo a precisare che non sono uno sviluppatore (mi sono dedicato ad altro già da tanti anni dopo aver fatto le mie esperienze su Assembler, C, Basic e un po di scriptame con diverse shell… e, forse, dopo aver capito che non ero un granché in quel ruolo).
Se ci sono degli sviluppatori che mi leggono vorrei il loro punto di vista su quello che ho scritto e magari anche quello di qualche imprenditore del software.
Ogni commento è sempre il benvenuto.
Parole Sante, Enrico!!!
Hai inanellato una serie di “cause” dello status attuale dello sviluppo software (IMHO), e mi permetto di aggiungere qualche altra riflessione.
Chi mi conosce sa che sono molto caustico (e in maniera vBastarda) sulla crescente distanza che c’e’ fra il mondo “infrastruttura” (comprendendo anche IaaS, ovviamente) e il mondo “developer” (con particolare riferimento a PaaS, e soprattutto alla sua mancata adozione). Il mondo infrastrutturale cresce e sta “tirando il carro” non perche’ e’ piu’ facile, ma perche’ da un punto di vista architetturale non e’ concesso a chi si occupa (seriamente) di infrastrutture di non avere una chiara visione dell’insieme. L’opposto avviene invece, ahime’, per il mondo dello sviluppo, dove TROPPO SPESSO (quasi sempre) il focus e’ orientato solo al problema da risolvere da un punto di vista funzionale, lasciando al caso anche i componenti architetturali piu’ importanti.
Design for scale? design for fail? magari! Il “problema” parte da lontano: nella maggior parte dei casi chi sviluppa non ha la minima idea di cosa significa mettere e mantenere in esercizio un servizio. Di conseguenza tematiche FONDAMENTALI che vanno dal capacity planning, alla scalabilita’, al monitoraggio, fino ad arrivare a tematiche “lunari” come il show/chargeback sono completamente ignorate. Come evidenzi giustamente, serve una visione piu’ condivisa di come e’ composta un’architettura moderna (sia dal punto di vista infrastrutturale, che da quello dei framework applicativi, che da quello della sicurezza, ecc), in modo da ragionare prendendo in considerazione dal “Day 1” le tematiche che inevitabilmente si dovranno affrontare.
Ancora oggi (2012, se non vado errato) ci tocca avere a che fare con software appena sfornati che non considerano, e tantomeno implementano/supportano funzionalita’ BASE come alta affidabilita’, bilanciamento, packaging (con la P maiuscola), monitoraggio (con la M maiuscola). Proviamo a pensare di spostare tutto cio’ su un’infrastruttura cloud (anche “solo” IaaS) ed ecco il disastro: componenti tightly coupled, che non hanno la minima concezione di scalabilità e resilienza.
E’ sicuramente un problema culturale, che ahinoi vanifica in parte l’evoluzione continua delle infrastrutture cloud (sopratutto PaaS). Ma non e’ solo un gap in termini di maturita’: in larga parte il problema e’ “voluto”. Non e’ mia intenzione fomentare la “teoria del complotto”, ma la triste realta’ e’ che alla stragrande maggioranza dei produttori di software (boxed o custom, fa lo stesso) fa molto, troppo comodo continuare con le metodologie tradizionali (aka cappio al collo).
L’ironia di tutto cio’ e’ che le architetture di tipo PaaS nascono anche e soprattutto per semplificare la vita di chi sviluppa. Quello che viene in chiesto in cambio e’ normale diligenza e buon senso nell’approfondire “il giusto” gli strumenti nuovi che si hanno a disposizione. Ma di nuovo, “paga” di piu’ reinventare la ruota, piuttosto che abbracciare metodologie e piattaforme che in altri continenti/pianeti stanno diventando standard “de facto”.
La zavorra costituita da questo modus operandi e’ il vero freno dell’innovazione, e contemporaneamente la causa numero 1 della pervasiva inefficenza dell’IT (ok ok, sono un filino di parte, avendo il cappello infrastrutturale).
Da inguaribile ottimista continuo a sperare che l’evoluzione delle metodologie, delle discipline, delle architetture aiuti il mondo degli sviluppatori a crescere come deve, e come puo’. Per esempio, sono un fermo “believer” della filosofia DevOps, che di sicuro puo’ spingere nella direzione della maggior consapevolezza reciproca fra mondo “sviluppatori” ed “esercizio”.
Volendo spezzare una lancia a favore di chi “almeno ci prova”, il mondo degli sviluppatori e’ stato anche confuso (e tutt’ora lo e’) da una raffica continua di evoluzioni (o presunte tali) dei linguaggi di programmazione e framework ad essi correlati, tali da rendere difficile un miglioramento continuo e governabile delle applicazioni. Mi riferisco al misero approccio in stile “over-engineering” tipico del mondo Java (che odio visceralmente per questo) che in decenni ha creato layer di inutile e insostenibile complessità con la promessa di disegni architetturali impeccabili.
I disegni saranno pure impeccabili sulla carta, ma alla prova dei fatti hanno fallito, praticamente tutti, miseramente.
Un po’ le cose stanno cambiando (anche nello sciagurato mondo Java) con le ventate di buon senso portate per es. da Spring framework. Purtroppo il reticolo di trappole modaiole e’ ancora fitto… ma un po’ alla volta.. 🙂
Come mai queste cose non capitano (o capitano MOLTO meno) nel mondo infrastrutturale? mica perche’ e’ piu’ semplice! (il contrario, casomai). La realta’ e’ che l’infrastruttura non si puo’ permettere questi epic fail. Per il semplice motivo che uno dei requisiti dell’infrastruttura e’ che deve funzionare, sempre (o almeno provarci).
Buona Pasqua! 🙂
PJ
PJ,
grazie del commento, che praticamente ha completato il mio post!
Buona Pasqua.
E
Parole Sante, Enrico!!!
Hai inanellato una serie di “cause” dello status attuale dello sviluppo software (IMHO), e mi permetto di aggiungere qualche altra riflessione.
Chi mi conosce sa che sono molto caustico (e in maniera vBastarda) sulla crescente distanza che c’e’ fra il mondo “infrastruttura” (comprendendo anche IaaS, ovviamente) e il mondo “developer” (con particolare riferimento a PaaS, e soprattutto alla sua mancata adozione). Il mondo infrastrutturale cresce e sta “tirando il carro” non perche’ e’ piu’ facile, ma perche’ da un punto di vista architetturale non e’ concesso a chi si occupa (seriamente) di infrastrutture di non avere una chiara visione dell’insieme. L’opposto avviene invece, ahime’, per il mondo dello sviluppo, dove TROPPO SPESSO (quasi sempre) il focus e’ orientato solo al problema da risolvere da un punto di vista funzionale, lasciando al caso anche i componenti architetturali piu’ importanti.
Design for scale? design for fail? magari! Il “problema” parte da lontano: nella maggior parte dei casi chi sviluppa non ha la minima idea di cosa significa mettere e mantenere in esercizio un servizio. Di conseguenza tematiche FONDAMENTALI che vanno dal capacity planning, alla scalabilita’, al monitoraggio, fino ad arrivare a tematiche “lunari” come il show/chargeback sono completamente ignorate. Come evidenzi giustamente, serve una visione piu’ condivisa di come e’ composta un’architettura moderna (sia dal punto di vista infrastrutturale, che da quello dei framework applicativi, che da quello della sicurezza, ecc), in modo da ragionare prendendo in considerazione dal “Day 1” le tematiche che inevitabilmente si dovranno affrontare.
Ancora oggi (2012, se non vado errato) ci tocca avere a che fare con software appena sfornati che non considerano, e tantomeno implementano/supportano funzionalita’ BASE come alta affidabilita’, bilanciamento, packaging (con la P maiuscola), monitoraggio (con la M maiuscola). Proviamo a pensare di spostare tutto cio’ su un’infrastruttura cloud (anche “solo” IaaS) ed ecco il disastro: componenti tightly coupled, che non hanno la minima concezione di scalabilità e resilienza.
E’ sicuramente un problema culturale, che ahinoi vanifica in parte l’evoluzione continua delle infrastrutture cloud (sopratutto PaaS). Ma non e’ solo un gap in termini di maturita’: in larga parte il problema e’ “voluto”. Non e’ mia intenzione fomentare la “teoria del complotto”, ma la triste realta’ e’ che alla stragrande maggioranza dei produttori di software (boxed o custom, fa lo stesso) fa molto, troppo comodo continuare con le metodologie tradizionali (aka cappio al collo).
L’ironia di tutto cio’ e’ che le architetture di tipo PaaS nascono anche e soprattutto per semplificare la vita di chi sviluppa. Quello che viene in chiesto in cambio e’ normale diligenza e buon senso nell’approfondire “il giusto” gli strumenti nuovi che si hanno a disposizione. Ma di nuovo, “paga” di piu’ reinventare la ruota, piuttosto che abbracciare metodologie e piattaforme che in altri continenti/pianeti stanno diventando standard “de facto”.
La zavorra costituita da questo modus operandi e’ il vero freno dell’innovazione, e contemporaneamente la causa numero 1 della pervasiva inefficenza dell’IT (ok ok, sono un filino di parte, avendo il cappello infrastrutturale).
Da inguaribile ottimista continuo a sperare che l’evoluzione delle metodologie, delle discipline, delle architetture aiuti il mondo degli sviluppatori a crescere come deve, e come puo’. Per esempio, sono un fermo “believer” della filosofia DevOps, che di sicuro puo’ spingere nella direzione della maggior consapevolezza reciproca fra mondo “sviluppatori” ed “esercizio”.
Volendo spezzare una lancia a favore di chi “almeno ci prova”, il mondo degli sviluppatori e’ stato anche confuso (e tutt’ora lo e’) da una raffica continua di evoluzioni (o presunte tali) dei linguaggi di programmazione e framework ad essi correlati, tali da rendere difficile un miglioramento continuo e governabile delle applicazioni. Mi riferisco al misero approccio in stile “over-engineering” tipico del mondo Java (che odio visceralmente per questo) che in decenni ha creato layer di inutile e insostenibile complessità con la promessa di disegni architetturali impeccabili.
I disegni saranno pure impeccabili sulla carta, ma alla prova dei fatti hanno fallito, praticamente tutti, miseramente.
Un po’ le cose stanno cambiando (anche nello sciagurato mondo Java) con le ventate di buon senso portate per es. da Spring framework. Purtroppo il reticolo di trappole modaiole e’ ancora fitto… ma un po’ alla volta.. 🙂
Come mai queste cose non capitano (o capitano MOLTO meno) nel mondo infrastrutturale? mica perche’ e’ piu’ semplice! (il contrario, casomai). La realta’ e’ che l’infrastruttura non si puo’ permettere questi epic fail. Per il semplice motivo che uno dei requisiti dell’infrastruttura e’ che deve funzionare, sempre (o almeno provarci).
Buona Pasqua! 🙂
PJ
PJ,
grazie del commento, che praticamente ha completato il mio post!
Buona Pasqua.
E
Quando leggo post di questo tipo mi viene sempre un pelino da sorridere, sopratutto perché é facile commentare il lavoro di altri.
Sarebbe carino vedere il codice prodotto dagli esperti per vedere quanto é lineare bello pulito senza bugs ed anche profumato :)!
I tools di alto livello sono necessari e sopratutto facilitano lo sviluppo, codice più pesante??? Che significa esattamente codice pesante ?
Poco gestibile ? In base a che criterio ? Se scrivi il codice più bello del mondo senza documentazione sei allo stesso punto.
Fuori luogo il post ,se mi permetti, perché come dici tu stesso non sei uno sviluppatore per cui non puoi conoscere le problematiche legate allo sviluppo di un sw.
Sulla mancanza di cultura nel Cloud ti do ragione.
Gabriele .
Gabriele,
apprezzo il commento ma non sono d’accordo.Non sono (più) sviluppatore ma non vuol dire che non mi sia informato, e che non raccolga le istanze di molti sviluppatori e dei loro responsabili quando giro….In ogni caso sviluppare è come tutti gli altri lavori, c’è chi è capace e c’è chi no. Un esempio: Se prendi il codice di alcuni progetti e lo guardi è leggibile anche a chi non mette le mani tutti i giorni sul codice, altri sono uno schifo mal documentato e di solito risulta anche quello più inefficiente (mi è capitato poco tempo fa con dei temi di WP che sto valutando per un nostro sito).In ogni caso, uno sviluppatore che non sa come funziona la tecnologia e gli strumenti che ha a disposizione è portato ad utilizzare male quello che conosce… costruendo codice su basi sbagliate. Immagino che ti sarà capitato di vedere mille volte dei loop con dei break in mezzo solo perché il costrutto è stato pensato da cani o non è quello giusto (parlo di C ovviamente).
Buona Pasqua!
E
Enrico,
Quello che dici è assolutamente esatto, cerco di difendere solo la categoria perché spesso ci troviamo a lavorare “male” per colpa di decisioni prese da altri.
Sono davvero poche le aziende che investono nella formazione, documentazione, test e tutti i cicli di vita del sw, per cui i programmatori spesso si trovano bloccati.Sulla filosofia della programmazione possiamo parlarne per mesi, senza uscirne.
Non sono uno di quelli che rimane fermo sui pochi concetti conosciuti, anzi seguo e studio continuamente le varie tecnologie e sono appassionato di middleware ( ho pubblicato anche dei post in merito).
Però spesso mi ritrovo a parlare da solo di alcune tecnologie perché sembrano concetti “strani” per cui si preferisce percorrere le buone e vecchie strade.
That’s all! :)!
Gabriele
Quando leggo post di questo tipo mi viene sempre un pelino da sorridere, sopratutto perché é facile commentare il lavoro di altri.
Sarebbe carino vedere il codice prodotto dagli esperti per vedere quanto é lineare bello pulito senza bugs ed anche profumato :)!
I tools di alto livello sono necessari e sopratutto facilitano lo sviluppo, codice più pesante??? Che significa esattamente codice pesante ?
Poco gestibile ? In base a che criterio ? Se scrivi il codice più bello del mondo senza documentazione sei allo stesso punto.
Fuori luogo il post ,se mi permetti, perché come dici tu stesso non sei uno sviluppatore per cui non puoi conoscere le problematiche legate allo sviluppo di un sw.
Sulla mancanza di cultura nel Cloud ti do ragione.
Gabriele .
Gabriele,
apprezzo il commento ma non sono d’accordo.Non sono (più) sviluppatore ma non vuol dire che non mi sia informato, e che non raccolga le istanze di molti sviluppatori e dei loro responsabili quando giro….In ogni caso sviluppare è come tutti gli altri lavori, c’è chi è capace e c’è chi no. Un esempio: Se prendi il codice di alcuni progetti e lo guardi è leggibile anche a chi non mette le mani tutti i giorni sul codice, altri sono uno schifo mal documentato e di solito risulta anche quello più inefficiente (mi è capitato poco tempo fa con dei temi di WP che sto valutando per un nostro sito).In ogni caso, uno sviluppatore che non sa come funziona la tecnologia e gli strumenti che ha a disposizione è portato ad utilizzare male quello che conosce… costruendo codice su basi sbagliate. Immagino che ti sarà capitato di vedere mille volte dei loop con dei break in mezzo solo perché il costrutto è stato pensato da cani o non è quello giusto (parlo di C ovviamente).
Buona Pasqua!
E
Enrico,
Quello che dici è assolutamente esatto, cerco di difendere solo la categoria perché spesso ci troviamo a lavorare “male” per colpa di decisioni prese da altri.
Sono davvero poche le aziende che investono nella formazione, documentazione, test e tutti i cicli di vita del sw, per cui i programmatori spesso si trovano bloccati.Sulla filosofia della programmazione possiamo parlarne per mesi, senza uscirne.
Non sono uno di quelli che rimane fermo sui pochi concetti conosciuti, anzi seguo e studio continuamente le varie tecnologie e sono appassionato di middleware ( ho pubblicato anche dei post in merito).
Però spesso mi ritrovo a parlare da solo di alcune tecnologie perché sembrano concetti “strani” per cui si preferisce percorrere le buone e vecchie strade.
That’s all! :)!
Gabriele
In riferimento alla realtà attuale (lavoro per provider che eroga servizi cloud, PaaS compresi) do assolutamente ragione ad Enrico e ancor di più a PJ che ha ben inquadrato la questione.
Ora, ritengo che nessuno voglia fare di tutta l’erba un fascio, ma è un dato di fatto che la maggioranza dei programmatori non si curano minimamente di aspetti base come le risorse che serviranno per far girare il loro programma… e ci troviamo con meravigliose applicazioni che abbisognano di 32 GB di RAM per asservire 10 utenti simultanei (case history reale).
Il “problema” è che oggi le infrastrutture permettono di “sbragare”, ma la cosa ha un costo che qualcuno dovrà sostenere e non è detto che costi meno rispetto ad un investimento in “buona programmazione”.
E’ assolutamente saggio evidenziare a chi si occupa di sviluppo di prendere in considerazione certi temi, non dico di tornare alle paranoie meravigliose dalle “scena demo”, ma il buon codice è senza dubbio preferibile.
Ciao!
In riferimento alla realtà attuale (lavoro per provider che eroga servizi cloud, PaaS compresi) do assolutamente ragione ad Enrico e ancor di più a PJ che ha ben inquadrato la questione.
Ora, ritengo che nessuno voglia fare di tutta l’erba un fascio, ma è un dato di fatto che la maggioranza dei programmatori non si curano minimamente di aspetti base come le risorse che serviranno per far girare il loro programma… e ci troviamo con meravigliose applicazioni che abbisognano di 32 GB di RAM per asservire 10 utenti simultanei (case history reale).
Il “problema” è che oggi le infrastrutture permettono di “sbragare”, ma la cosa ha un costo che qualcuno dovrà sostenere e non è detto che costi meno rispetto ad un investimento in “buona programmazione”.
E’ assolutamente saggio evidenziare a chi si occupa di sviluppo di prendere in considerazione certi temi, non dico di tornare alle paranoie meravigliose dalle “scena demo”, ma il buon codice è senza dubbio preferibile.
Ciao!
Ciao,
effettivamente gli sviluppatori sono ignoranti per 2 motivi:
1) fino a poco tempo fa il paradigma è sempre e soltanto “scalabilità verticale”: sia l’hw che i vendor hanno viziato gli sviluppatori a pensare che, se ci sono problemi di performance, basta comprare qualcosa di più grosso
2) la scalabilità orizzontale è relativamente facile lato HW (comperi N macchine, le metti dietro un loadbalancer e molto a grandi linee il gioco è fatto) mentre per quanto riguarda il software diventa un vero inferno (concorrenza, coerenza, etc etc). Per questo motivo sono nati tutta una nuova serie di concetti come sharding, NoSQL, cache distribuite che sono difficili da capire e da maneggiare anche dagli stessi cugini americani all’avanguardia su questi temi. Se a questo aggiungiamo l’arretratezza storica e culturale nostra, la mancanza di pianificazione, l’abbondanza delle poche idee e ben confuse il mix diventa perfetto.
Sono il primo a sapere che il problema sono gli applicativi o quanto meno applicativi “cloud-aware” nel senso di applicative non che debbano per forza essere rilasciati in una qualche PAAS quanto applicativi che siano scritti con la scalabilità orizzontale come primo requisito.
Ciaoo
Piero
Ciao,
effettivamente gli sviluppatori sono ignoranti per 2 motivi:
1) fino a poco tempo fa il paradigma è sempre e soltanto “scalabilità verticale”: sia l’hw che i vendor hanno viziato gli sviluppatori a pensare che, se ci sono problemi di performance, basta comprare qualcosa di più grosso
2) la scalabilità orizzontale è relativamente facile lato HW (comperi N macchine, le metti dietro un loadbalancer e molto a grandi linee il gioco è fatto) mentre per quanto riguarda il software diventa un vero inferno (concorrenza, coerenza, etc etc). Per questo motivo sono nati tutta una nuova serie di concetti come sharding, NoSQL, cache distribuite che sono difficili da capire e da maneggiare anche dagli stessi cugini americani all’avanguardia su questi temi. Se a questo aggiungiamo l’arretratezza storica e culturale nostra, la mancanza di pianificazione, l’abbondanza delle poche idee e ben confuse il mix diventa perfetto.
Sono il primo a sapere che il problema sono gli applicativi o quanto meno applicativi “cloud-aware” nel senso di applicative non che debbano per forza essere rilasciati in una qualche PAAS quanto applicativi che siano scritti con la scalabilità orizzontale come primo requisito.
Ciaoo
Piero
Ciao, mi sono avvicinato da poco al nuovo mondo del cloud, ma per 30 anni ho avuto un’azienda di informatica dal mondo dei sistemi tradizionali (S36, AS/400) e sviluppo web java db ed altro.
Il vecchio detto nei CED era e penso lo sia ancora è: “all’esercizio se tutto va bene si fa pari” e vi assicuro che in ambienti complessi (tre mainframe, 21 AS/400, SNA, TCP/IP, 30 servers windows, 4 aix) è difficile che una notte di elaborazione e backup vari vada sempre tutto bene.
Relativamente allo sviluppo applicativo bisogna dire che chi sviluppa (o chi vende il software) usa il suo potere sul cliente (interno o esterno) in maniera inadeguato (tanto è il business che paga); ma sopratutto non gli è richiesto, specialmente nelle softwarhouse, la conoscenza degli ambienti tecnologici di delivery e delle regole di esercizio.
Molte volte ho dovuto fare audit su applicativi che facevano elaborazioni chilometriche solo perchè scrivevano file sequenziali di milioni di records enne volte e li indicizzavano in maniera dinamica …..
Retaggi di ambienti con schede e sorter machines….
Purtroppo in una politica del lavoro a contratto (progetto), non c’è spazio per fare la qualità (motivo per cui ho chiuso l’azienda). Andare a spiegare ai clienti quali sono le differenze tra avere un ambiente monitorato e monitorabile, rispetto al fatto che comunque l’applicazione deve stampare le fatture (due cose lontane anni luce tra loro) è impresa ardua e comunque alla fine quello che fa la differenza è l’addizione o il billing che dir si voglia.
Non è un problema di linguaggi (niente di nuovo sotto il sole) e nemmeno di protocolli di comunicazione o S.A.N., ma solamente di cultura T.C.O. (costo totale per il business) e quindi di logica manageriale e conoscenza aziendale seria di tutte le componenti che entrano in ballo: commerciali (devono fare numeri), capi progetto (gestiscono le risorse di altri), imprenditori del software (vendono cose non loro), sviluppatori (devono lavorare a cottimo sottopagato senza sapere che fine farà il loro programma). Per quanto riguarda le infrastrutture sono pezzi di ferro e basta premere l’interruttore e si accendono… Conoscete sviluppatori web che conoscono seriamente il TCP/IP, routing, DNS ed affini? Oppure SysAdmin che conoscono le problematiche applicative (magazzino e bollettazione) per poter comprendere chi sono gli utenti che vivono dietro a quel servizio? Abbiamo bisogno, specialmente nelle aziende piccole, che si diffondano culture a tutto tondo realmente, e che si investa sulla qualità del lavoro che purtroppo è fatto dalle persone e non dalle macchine o dai software. Sono troppo pessimista?
Massimo, ho apprezzato molto il tuo commento che condivido pienamente, quello che forse si avvicina di più a quello che chiedi nell’ultima parte del commento è la figura del DevOps di cui parla PJ in uno degli altri commenti.
Purtroppo il punto focale di tutto il discorso è la cultura, nel mondo IT (in generale, forse in Italia particolarmente) manca la cultura generale di tutto quello che è l’ambiente IT, molto spesso errori grossolani a livello applicativo potrebbero essere risolti semplicemente conoscendo come l’infrastruttura lavora nel layer sottostante, e viceversa, forse la figura del DevOps e dell’ IT generalist è quella su cui puntare per colmare questa lacuna.
ciao,
Fabio
Ciao, mi sono avvicinato da poco al nuovo mondo del cloud, ma per 30 anni ho avuto un’azienda di informatica dal mondo dei sistemi tradizionali (S36, AS/400) e sviluppo web java db ed altro.
Il vecchio detto nei CED era e penso lo sia ancora è: “all’esercizio se tutto va bene si fa pari” e vi assicuro che in ambienti complessi (tre mainframe, 21 AS/400, SNA, TCP/IP, 30 servers windows, 4 aix) è difficile che una notte di elaborazione e backup vari vada sempre tutto bene.
Relativamente allo sviluppo applicativo bisogna dire che chi sviluppa (o chi vende il software) usa il suo potere sul cliente (interno o esterno) in maniera inadeguato (tanto è il business che paga); ma sopratutto non gli è richiesto, specialmente nelle softwarhouse, la conoscenza degli ambienti tecnologici di delivery e delle regole di esercizio.
Molte volte ho dovuto fare audit su applicativi che facevano elaborazioni chilometriche solo perchè scrivevano file sequenziali di milioni di records enne volte e li indicizzavano in maniera dinamica …..
Retaggi di ambienti con schede e sorter machines….
Purtroppo in una politica del lavoro a contratto (progetto), non c’è spazio per fare la qualità (motivo per cui ho chiuso l’azienda). Andare a spiegare ai clienti quali sono le differenze tra avere un ambiente monitorato e monitorabile, rispetto al fatto che comunque l’applicazione deve stampare le fatture (due cose lontane anni luce tra loro) è impresa ardua e comunque alla fine quello che fa la differenza è l’addizione o il billing che dir si voglia.
Non è un problema di linguaggi (niente di nuovo sotto il sole) e nemmeno di protocolli di comunicazione o S.A.N., ma solamente di cultura T.C.O. (costo totale per il business) e quindi di logica manageriale e conoscenza aziendale seria di tutte le componenti che entrano in ballo: commerciali (devono fare numeri), capi progetto (gestiscono le risorse di altri), imprenditori del software (vendono cose non loro), sviluppatori (devono lavorare a cottimo sottopagato senza sapere che fine farà il loro programma). Per quanto riguarda le infrastrutture sono pezzi di ferro e basta premere l’interruttore e si accendono… Conoscete sviluppatori web che conoscono seriamente il TCP/IP, routing, DNS ed affini? Oppure SysAdmin che conoscono le problematiche applicative (magazzino e bollettazione) per poter comprendere chi sono gli utenti che vivono dietro a quel servizio? Abbiamo bisogno, specialmente nelle aziende piccole, che si diffondano culture a tutto tondo realmente, e che si investa sulla qualità del lavoro che purtroppo è fatto dalle persone e non dalle macchine o dai software. Sono troppo pessimista?
Massimo, ho apprezzato molto il tuo commento che condivido pienamente, quello che forse si avvicina di più a quello che chiedi nell’ultima parte del commento è la figura del DevOps di cui parla PJ in uno degli altri commenti.
Purtroppo il punto focale di tutto il discorso è la cultura, nel mondo IT (in generale, forse in Italia particolarmente) manca la cultura generale di tutto quello che è l’ambiente IT, molto spesso errori grossolani a livello applicativo potrebbero essere risolti semplicemente conoscendo come l’infrastruttura lavora nel layer sottostante, e viceversa, forse la figura del DevOps e dell’ IT generalist è quella su cui puntare per colmare questa lacuna.
ciao,
Fabio
Ciao,
scrivo codice da ormai 28 anni (ho cominciato quando ne avevo 13 con il mitico Commodore 64) e anch’io ne ho viste veramente di tutti i colori.
Sono pienamente d’accordo con te, ma ritengo che il problema sia dovuto al fatto che tante persone senza basi né competenze specifiche, si sono spacciate per programmatori (autodidatti) solo perchè l’informatica è un settore dove ancora c’è lavoro e hanno trovato terreno fertile perchè le aziende tendono ad acquistare manovalanza a basso costo. Il risultato è poi quello che hai descritto, con noi professionisti che ne subiamo le conseguenze.
A mio parere è assurdo che un laureato in Architettura faccia il programmatore (come mi è accaduto di vedere qualche anno fa).
Purtroppo il problema esiste solo in italia. All’estero il programmatore è una figura professionale rispettata e valorizzata.
Ciao,
scrivo codice da ormai 28 anni (ho cominciato quando ne avevo 13 con il mitico Commodore 64) e anch’io ne ho viste veramente di tutti i colori.
Sono pienamente d’accordo con te, ma ritengo che il problema sia dovuto al fatto che tante persone senza basi né competenze specifiche, si sono spacciate per programmatori (autodidatti) solo perchè l’informatica è un settore dove ancora c’è lavoro e hanno trovato terreno fertile perchè le aziende tendono ad acquistare manovalanza a basso costo. Il risultato è poi quello che hai descritto, con noi professionisti che ne subiamo le conseguenze.
A mio parere è assurdo che un laureato in Architettura faccia il programmatore (come mi è accaduto di vedere qualche anno fa).
Purtroppo il problema esiste solo in italia. All’estero il programmatore è una figura professionale rispettata e valorizzata.
Salve ho letto il post e i vostri commenti e mi piacerebbe
dire anche la mia a riguardo. Parto da un concetto letto nel post che mi ha
colpito perchè secondo me dice una gran bella verità e spesso questa cosa la
riscontro in diversi gruppi di lavoro .
In un punto del post è scritto: “E’ vero c’è internet, quindi il giovane sviluppatore potrebbe anche
“autoformarsi” ma, da un lato capisco sia comunque difficile, dall’altro ha un
costo.
Inoltre, e questo è un dato di fatto, è inutile pensare di investire
personalmente per diventare uno vero “sviluppatore per il cloud” quando poi non
si ha la possibilità di mettere a disposizione il proprio sapere ed essere
valorizzati per per le proprie capacità: l’entusiasmo si spegne presto se non
lo sia alimenta con sfide e successi!”
Appartengo purtroppo alla categoria dei programmatori java,
e dico purtroppo perché anche se questo potrebbe essere un settore divertente spesso
non lo è, da programmatore sono io la prima a rispecchiarmi nel concetto sopra
citato. Come dice Gabriele spesso ci troviamo a lavorare male per decisione
prese da altri, probabilmente dipende dai progetti e dai contesti (a mio avviso
lavorare per la pubblica amministrazione è il caso peggiore)ma spesso noi
programmatori siamo trattati come delle macchine: fai questo, fai quello e
soprattutto sbrigati perché questa cosa che ti chiedo oggi doveva essere pronta
per ieri. E’ chiaro che in queste condizioni si lavora molto male e se poco
poco provi a dire che magari è utile ragionare su quali siano le scelte tecniche
migliori per portare avanti uno sviluppo
software nel migliore dei casi ti viene detto: “va bene fai quello che ti pare
se ti senti in grado di finire entro subito”,
nel peggiore dei casi ti viene detto “sono io quello che decide le
scelte tecniche tu devi eseguire solo quello che ti dico di fare”. Se quello
che ci viene detto di fare fosse sempre la scelta migliore in termini di
prestazione, di peso del codice e di utilizzo corretto di tecnologie sarebbe
ottimo perché per un programmatore inesperto ci sarebbe solo da imparare,
peccato che spesso queste scelte “dettate dall’alto” spesso è evidente anche al
programmatore più inesperto, sono solo delle boiate. Tutto ciò succede perché al
programmatore spesso non è dato di prendere decisioni tecniche legate ad un
analisi tecnica fatta bene, ma non c’è nemmeno un elemento all’interno del
gruppo di sviluppo a cui è delegato questo ruolo, o chi dovrebbe farlo non è in
grado di farlo. Le ragioni per cui si verificano queste cose potrebbero essere svariate,
tra queste sicuramente la mancanza di investimenti da parte delle società nella
formazione di studiare le infrastrutture nuove e capirne i vantaggi e
sicuramente anche gli svantaggi che posso comportare. Alla base di questo ci
sono ragioni economiche? Probabilmente si, ma il risultato di tutto è che
lavorare in ambienti cosi non è stimolante e anche volendo fare autoformazione da
internet sapendo di non riuscire forse mai ad utilizzare il
proprio sapere non è scoraggiante ma rappresenta proprio la morte di ogni
entusiasmo, ragion per cui tra gli sviluppatori spesso il clima che trovo è di “adeguamento”
alla situazione, mancanza di voglia di scoprire il nuovo anzi di più a pensare
al nuovo non ci si arriva proprio perché si passano le giornate a cercare di
portare avanti i task cercando di non trovarsi in situazioni di disagio in cui
tutto ciò che non funziona dipende dal programmatore che ha fatto cavolate solo
perché fa i copia e incolla senza immaginare minimante ciò che c’è dietro. Certo
mi trovo d’accordo con Enrico quando dice che uno sviluppatore che non conosce
come funziona le tecnologia e gli strumenti che ha a disposizione utilizza male
quello che conosce, ma credo che il problema sia a monte perché se è vero
questo è anche vero che spesso queste situazioni non vengono generate dai
programmatori che, ripeto, spesso sono considerate delle macchine da codice, ma
da chi detta scelte che il programmatore si trova a dover eseguire. Ciò non
toglie che tra i programmatori si trovano poi molti che si nascondono dietro a
ciò per continuare a far male il proprio lavoro continuando i copia e incolla
sterili che non servono a nessuno.
Maricarmela,
grazie per il contributo.
Salve ho letto il post e i vostri commenti e mi piacerebbe
dire anche la mia a riguardo. Parto da un concetto letto nel post che mi ha
colpito perchè secondo me dice una gran bella verità e spesso questa cosa la
riscontro in diversi gruppi di lavoro .
In un punto del post è scritto: “E’ vero c’è internet, quindi il giovane sviluppatore potrebbe anche
“autoformarsi” ma, da un lato capisco sia comunque difficile, dall’altro ha un
costo.
Inoltre, e questo è un dato di fatto, è inutile pensare di investire
personalmente per diventare uno vero “sviluppatore per il cloud” quando poi non
si ha la possibilità di mettere a disposizione il proprio sapere ed essere
valorizzati per per le proprie capacità: l’entusiasmo si spegne presto se non
lo sia alimenta con sfide e successi!”
Appartengo purtroppo alla categoria dei programmatori java,
e dico purtroppo perché anche se questo potrebbe essere un settore divertente spesso
non lo è, da programmatore sono io la prima a rispecchiarmi nel concetto sopra
citato. Come dice Gabriele spesso ci troviamo a lavorare male per decisione
prese da altri, probabilmente dipende dai progetti e dai contesti (a mio avviso
lavorare per la pubblica amministrazione è il caso peggiore)ma spesso noi
programmatori siamo trattati come delle macchine: fai questo, fai quello e
soprattutto sbrigati perché questa cosa che ti chiedo oggi doveva essere pronta
per ieri. E’ chiaro che in queste condizioni si lavora molto male e se poco
poco provi a dire che magari è utile ragionare su quali siano le scelte tecniche
migliori per portare avanti uno sviluppo
software nel migliore dei casi ti viene detto: “va bene fai quello che ti pare
se ti senti in grado di finire entro subito”,
nel peggiore dei casi ti viene detto “sono io quello che decide le
scelte tecniche tu devi eseguire solo quello che ti dico di fare”. Se quello
che ci viene detto di fare fosse sempre la scelta migliore in termini di
prestazione, di peso del codice e di utilizzo corretto di tecnologie sarebbe
ottimo perché per un programmatore inesperto ci sarebbe solo da imparare,
peccato che spesso queste scelte “dettate dall’alto” spesso è evidente anche al
programmatore più inesperto, sono solo delle boiate. Tutto ciò succede perché al
programmatore spesso non è dato di prendere decisioni tecniche legate ad un
analisi tecnica fatta bene, ma non c’è nemmeno un elemento all’interno del
gruppo di sviluppo a cui è delegato questo ruolo, o chi dovrebbe farlo non è in
grado di farlo. Le ragioni per cui si verificano queste cose potrebbero essere svariate,
tra queste sicuramente la mancanza di investimenti da parte delle società nella
formazione di studiare le infrastrutture nuove e capirne i vantaggi e
sicuramente anche gli svantaggi che posso comportare. Alla base di questo ci
sono ragioni economiche? Probabilmente si, ma il risultato di tutto è che
lavorare in ambienti cosi non è stimolante e anche volendo fare autoformazione da
internet sapendo di non riuscire forse mai ad utilizzare il
proprio sapere non è scoraggiante ma rappresenta proprio la morte di ogni
entusiasmo, ragion per cui tra gli sviluppatori spesso il clima che trovo è di “adeguamento”
alla situazione, mancanza di voglia di scoprire il nuovo anzi di più a pensare
al nuovo non ci si arriva proprio perché si passano le giornate a cercare di
portare avanti i task cercando di non trovarsi in situazioni di disagio in cui
tutto ciò che non funziona dipende dal programmatore che ha fatto cavolate solo
perché fa i copia e incolla senza immaginare minimante ciò che c’è dietro. Certo
mi trovo d’accordo con Enrico quando dice che uno sviluppatore che non conosce
come funziona le tecnologia e gli strumenti che ha a disposizione utilizza male
quello che conosce, ma credo che il problema sia a monte perché se è vero
questo è anche vero che spesso queste situazioni non vengono generate dai
programmatori che, ripeto, spesso sono considerate delle macchine da codice, ma
da chi detta scelte che il programmatore si trova a dover eseguire. Ciò non
toglie che tra i programmatori si trovano poi molti che si nascondono dietro a
ciò per continuare a far male il proprio lavoro continuando i copia e incolla
sterili che non servono a nessuno.
test
test2
test3
test4