Storie dalla Sala Macchine

Lo sai, per assurdo è un metodo che usano adesso per "tenersi" il cliente.

Lo sai meglio di me che il "managment" non capisce principalmente un guazzo di informatica, e tutti questi problemi ricorrenti che succedono, hanno come unico risultato quello di farlo impaurire di più.

Il risultato è perverso.

Non cambiano il programma, perché hanno paura che quello successivo non faccia altro che disastri maggiori di quelli che già succedono quotidianamente. Non chiedono bug-fixes perché se no devono sborsare un sacco di soldi per roba che fondamentalmente già sanno che non funziona...

Infine non cambiano il fornitore perché la gente (seria) che vede le ciofeche che usano si mette le mani nei capelli e spara cifroni da paura.

La colpa è poi sempre dell'incompetenza di chi la vora internamente all'azienda, sia chiaro!

E' un circolo vizioso...

-- Giordano

>La colpa è poi sempre dell'incompetenza di chi lavora internamente all'azienda, sia chiaro!

Si, ma stramegaca$$o, capisco che l'utonto medio non sappia che accidenti vuole che faccia il software che chiede lui stesso di sviluppare, ma da qui a far fare da beta (o alfa??) tester al povero galoppino che deve installare la fetenzia (e poi sorbirsi le lamentele di tutti i CL, UL, SUSL...) ce ne passa!

(si vede che sto installando un merdaviglioso gestionale nuovo?).

(sappiate che QUALSIASI errore dato da quel coso è "Errore 3". Abbiamo scovato un altro caso di codice ben documentato).

Buona settimana.

('na sega).

 

 

 

-- Andrea

Solo una nota: quello che hai descritto non è l'applicazione dello sviluppo agile.

È semplicemente diventato (sta diventando) mainstream, quindi tutti ne parlano senza mai averlo usato, o applicato alla membro riproduttivo canino. Quindi quelli che ti ritrovi sono i soliti coglioni che vedono una nuova buzzword e la mettono a curriculum.

Innanzitutto serve il cervello (cosa che noto molto spesso mancare - in genere purtroppo...), e poi normalmente quello che viene consegnato è largamente testato (partendo dai test o introducendoli dopo non ha importanza nel prodotto finito - è utile solo ed esclusivamente agli sviluppatori).

L'unica cosa è il tempo di sviluppo suddiviso in sessioni molto brevi giusto per controllare insieme al cliente se le cose stanno andando nel verso giusto o bisogna correggere la rotta. Che se non si fa non si è agili per un cazzo ma solo di nome (sbagliato tra l'altro...).

Inoltre, i veri agilisti mica te lo dicono che stanno usando agile: a te come cliente frega una cippa, a te interessa solo che funzioni, poi sta allo sviluppatore interagire col cliente per fare in modo che ciò accada

-- blackpingus

purtroppo sono d'accordo su tutto... non ho anni di esperienza come programmatore, ma noto che i vari conslutanti che passano in azienda hanno un approccio molto "superficiale" all'analisi, si mettono subito a "scrivere codice" (aka copiaincollano dai forum) per mostrare qualcosa di "usabile" in 2 giorni.

Fa niente se poi una volta installato non va un tubo...

-- IgorB

Ed io che credevo di essere l'unico a vederla cosi'... sono quasi commosso. -- Cip

Una descrizione della realtà assolutamente perfetta :-(

-- Io me medesimo

D'altronde, se fornissero subito una cosa funzionante, come farebbero a vendere le consulenze successive?

-- Daniele

> Che ci volete fare, sara' l'eta', o forse e' che il clima comincia a tendere allo schifido con temperature sotto lo zero ed ogni volta che capita pare che agli olandesi si surgeli del tutto quel poco cervello che hanno e le loro gia' scarse capacita' di guidare scompaiono del tutto.

Ecco, credo che questo concetto sia applicabile a tutte le genti del mondo civilizzato e non. Infatti, io ho la teoria, che se tu vivessi in Italia, diresti la stessa cosa degli italiani. Ergo, non è che gli Olandesi siano peggiori di altri, sei tu che non hai pazienza

> No, non mi sono mai fatto convincere da quell'aborto di Object-Pascal che passa sotto il nome di Delphi perche' mi apparve chiaro fin da subito che il management della Borland era composto da babbuini affetti dal morbo di Down

Sono completamente d'accordo! Non so perché uno dovrebbe sviluppare in quello pseudo accrocchio, e bada che io parlo con la concezione di uno che non l'ha quasi mai usato, figurati uno che lo usa tutti i giorni. Un nostro conslutante ci ha fatto un'applicazione in Delphi e credo che da allora il girone dei bestemmiatori si sia allargato di almeno un paio di palazzi costruiti appositamente per me e la mia collega da quando mettiamo le mani in quell'applicazione.

Comunque, sullo sviluppo di programmi/accrocchi/evari, posso dirti per esperienza che anche la vecchia scuola (chiedi al cliente cosa vuole) non funziona tanto bene, dato che, spesso e volentieri, il cliente non ha la MINIMA idea di quello che vuole o che gli serve, e di solito ti chiede un'applicazione solo perché fa tanto figo avere una roba su internet con il logo dell'azienda...

-- "I was watching the London Marathon and saw one runner dressed as a chicken and another runner dressed as an egg. I thought: 'This could be interesting.'" -Paddy Lennox
---
D.

I manager delle aziende di informatica nonché i loro committenti solitamente dimenticano che:
"Agile development" != "Ad nutum development"

Ovvero che tutte le attività di requisitazione, analisi, prototipazione, test, deployment cui fai riferimento tu non è che con le "metodologie agili" spariscano: anzi, devi ripeterle N-volte per tante quante sono le iterazioni che ti servono per convergere al prodotto finale.
E in tutto questo il "prodotto intermedio" non è una versione non funzionante del prodotto finale (che invece si chiama solo "prodotto finale incompleto e sul quale dobbiamo ancora lavorare"), ma una versione FUNZIONANTE ma con funzionalità ridotte.

Vallo a far capire a manager, formatisi sul six sigma e amenità simili, che pensano che sviluppare software sia analogo a produrre automobili alla T(r)oyota.
-- Anonymous coward

Mah, per una volta, non mi trovi in completo accordo con te...

Nel senso che molti di quei paradigmi che tu dici potrebbero funzionare se non ci fosse un telefono senza fili tra "chi vuole un aggeggio" e "chi fa l'aggeggio"...

Della serie, quando tu hai bisogno di un idraulico, chiami l'idraulico, right? Il settore informatico è uno dei pochi settori dove, quando hai bisogno di un idraulico, chiami il vicino di casa, che senta suo cugino, che contatti il cane dell'elettricista che senta l'idraulico..

Il fatto che ormai chiunque sappia fare un if si definisca programmatore, per me è un'altra storia....

-- Davide

fantstiche le "prescrizioni del tempo"

 

assume pioggia per 5gg due volte a dí, poi passi a schiarite per una settimana

concludere la terapia con 15gg di sole  

 

grazie par la storia come al solito!

-- Anonymous forecast coward

Sottoscrivo al 100%.

Lavoro in proprio ormai da qualche anno, e purtroppo devo confermare che per me è lo stesso. Giuro che io ci provo a mettere giù delle specifiche decenti (non buone, ma almeno decenti, che garantiscano un minimo di tutela a me e al cliente) ma non c'è verso.

Prima hanno cominciato le software house con le specifiche lazy (ma mooolto lazy) e poi, a stretto giro, gli sono andati dietro i clienti.

Risultato: vai a fare un primo incontro con il cliente che ti spiega per sommi (e confusi) capi quello che vuole; tu ci mediti sopra, abbozzi un'idea su come portare avanti le cose e lo ricontatti per definire bene i dettagli e fare una specifica adeguata.

Specifica? Quale specifica? "La specifica è quella che abbiamo detto l'altra volta.."

E se non ti fai andare bene questo modo di procedere, cercano un'altro.

Ovviamente, ça va sans dire, i dettagli sui quali non hanno voluto riflettere PRIMA sono modifiche che DEVI fargli DOPO. Naturalmente "era ovvio che doveva essere così" ed è altrettanto ovvio che "deve rientrare nel preventivo".

A questo punto non so più neanche con chi prendermela.

-- Anonimo codardo (e sputasentenze)

Illuminante, ma più che kamasutra-developer direi supercazzola-developer. Al prossimo giro, quando qualcuno se ne uscirà fuori con IL linguaggio di programmazione basato su multicore e intelligenza artificiale, dirà che il tuo intelligence server non é abbastanza intelligente per il suo software e che lui (aka, ma non penso sia realmente il caso di specificarlo, é colpa tua).

E cmq quando comincerai ad usare la sigla PT (programmatroto) piuttosto che CL?

-- http://limacat.blogspot.com

Da un po' di tempo mi chiedo sempre (soprattutto in ambito informatico) MA PERCHE' TUTTO DEVE SEMPRE PEGGIORARE MAN MANO CHE SI VA AVANTI?! Cioè, non dovremmo essere una razza che si evolve continuamente? Questa è evoluzione, sì ma al contrario...

-- Mg

 

Da un po' di tempo mi chiedo sempre (soprattutto in ambito informatico) MA PERCHE' TUTTO DEVE SEMPRE PEGGIORARE MAN MANO CHE SI VA AVANTI?! Cioè, non dovremmo essere una razza che si evolve continuamente? Questa è evoluzione, sì ma al contrario...

Che il cervello umano fosse 1500cc (circa) nell'epoca rinascimentale e che poi si sia ridotto di 1400-1200cc (lo so la frenologia è stata dichiarata ciarlataneria)  secondo me qualche cosa vorra pure dire: sarà l'ennesima riduzione in namometri delle cpu ?

-- Anonymous coward

>> ed a quel punto saltavano fuori i 3 bazilliardi di problemi che il gatto della segretaria non era riuscito a scovare.

 

Gatto che si è dimostrato  infinitamente più competente nell'uso del programma, rispetto al CL medio nello staff del cliente

-- Joshi Spawnbrød

Distruggere distruggere distruggere ...

-- Dotnette

Che orrore! Ho i brividi... Anche io avevo iniziato da programmatore, e sono finito a fare il sysadmin, pero` sono in fin dei conti contento di quello che faccio, proprio perche` fare il programmatore era piu` stressante che fare il sistemista.

Comunque condivido in pieno quello che pensi sul cosiddetto metodo agile (pur non essendo un programmatore, quindi la mia visione e` sicuramente limitata).

Se applicassimo il metodo agile alla amministrazione dei sistemi, sai che roba ne verrebbe fuori?

PS: Anche Giordano ha ragione da vendere. La ciofeca non si cambia perche` e` costata troppo, quindi va portata avanti perche` rappresenta un valore per l'azienda... e comunque rifarla costerebbe il triplo di troppo.

-- Il massimo danno con il minimo sforzo

Beh se ci pensi bene è una strategia vincente: perché perdere tempo quando i clienti pagano lo stesso senza che sia stato fatto testing? Se l'obiettivo non è acquisire professionalità e farsi un nome ma solo guadagnare tanti soldi è la cosa più furba da fare.

-- Emanuele

In questo periodo in università sto seguendo un corso di Ingegneria del Software... e tutta questa storia mi ha fatto riflettere non poco sulla sua utilità. (mettere qui storia lunga sulla tipologia di corso)

Grazie D. e buona mattina di mezzo inverno.

-- Anonymous coward

L'unico vero difetto del metodo di sviluppo illustrato dal buon (?) Davide è che l'utente spesso ha solo una pallida idea di cosa vorrebbe che il software facesse ed una insensata convinzione che nell'informatica tutto funzioni come in Star Trek: "Computer! Fammi questo e quello e già che ci sei dimmi quanto tempo ci vorrà per farlo." 

-- Anonymous coward

> Ci tengo subito a precisare che non approvero' nessuno dei loro commenti e quindi potete pure risparmiarvi la fatica.

No, che peccato! Erano la parte più divertente da leggere! Loro che parlavano di agile-supercazzoling e tu che li lartavi!

-- Aleritty

porca miseria se hai ragione...fortuna che almeno qui in molti casi posso contare su un capo "con le paxxe" che quando vede una cosa che fa schifo larta chi ci porta quella cosa fino a farla scappare...purtroppo non sempre può farlo ed è così che ci troviamo fetecchie di apparati di videoconferenza che non vanno

-- argaar

buongiorno davide

premesso che come te anche io ho cominciato a lavorare sugli home commodore di 2da mano (ma era un vic20) in basic prima ma passato quasi subito sull' assembler, vorrei suggerirti 2 cose:

- un corso di meditazione zen

- oppure  pantoprazolo: per lo stomaco fa miracoli (esperienza diretta)

ciao e buona giornata

WM

-- WM

il problema (e non c'entra niente apple) è che "ai tuoi tempi" (e anche ai miei) la procedure si potevano applicare perché non c'era nessun $manager a dirti che "costi troppo e devi fare le stesse cose in meno tempo perché altimenti $cliente va da $programmatorecantinaro che fa la stessa cosa [che in realtà nonè+ mai la stessa, ma difficilmente $cliente vede la differenza] in metà tempo e e metà prezzo".

-- applemacifonefanboyz

Penso che il problema è che non si fanno più le soluzioni "custom" (ad uso e consumo di 1 cliente, con i suoi problemi) ma vengono scelti dal management dei "pacchetti" generici senza prevedere alcun costo per customizzazione/adattamento.

Perchè altrimenti il software si sviluppa ancora come dici tu:

Analisi funzionale -> analisi tecnica -> sviluppo -> test (+fix) -> performance test -> pilota -> bug fix -> produzione

 

D.

-- Anonymous coward

cambia posto di lavoro, ne esistono dove i tuoi racconti dell'orrore sono solo cose divertenti lette su un sito di rantoli a caso

-- Anonymous coward

L'unica cosa certa è che il gatto della segretaria è un utente migliore di molti altri posti di fronte a un monitor...

-- Tatsumaki

Finché le foxxute analisi funzionali e il testing li fan fare ai laureati in Economia e Commercio (notoriamente dei NERD informatici che gli strumenti di sviluppo non san manco con che icona si aprono) i risultati sono quelli da te descritti... xD

Scrivo questo dopo aver rifatto per la bellezza di 12 volte gli stessi sviluppi grazie ai magici fogli eCCsel e le slide PowerPunto incomprensibili che ho visto in 4 mesi di lavoro...

-- artax

Finché le foxxute analisi funzionali e il testing li fan fare ai laureati in Economia e Commercio (notoriamente dei NERD informatici che gli strumenti di sviluppo non san manco con che icona si aprono) i risultati sono quelli da te descritti... xD

Scrivo questo dopo aver rifatto per la bellezza di 12 volte gli stessi sviluppi grazie ai magici fogli eCCsel e le slide PowerPunto incomprensibili che ho visto in 4 mesi di lavoro...

Ma guarda...ti darei anche ragione in tempi migliori....ma non essendo tempi migliori, ti dico che il problema non e' li: MAGARI fosse li, un tecnico serio (armato di un tubo di gomma dura) potrebbe "risolvere" facilmente queste mancanze !

il problema sta' molto prima: da molti anni il $cliente non vuole piu comprare "applicazioni", vuole affittare "personale per lo sviluppo" per la PROPRIA applicazione. Di conseguenza, quelle poche "software house" che esistevano prima sono diventate una mandria interminabile di "societa' di consulenza", che non vendono applicazioni ma forniscono al cliente(da ora $pollo) quello che vuole veramente: essere spennato.

Questo conviene al $fornitore perche' "ai bei tempi", quando si sviluppavano applicazioni chiavi in mano, hanno assunto una quantita industriale di $canieporci che ora devono essere impiegati in qualche modo per non essere un costo inutile, e quale modo migliore per spennarli se non  affittare gli stessi $canieporci a $pollo, a 5 volte il loro costo effettivo e per un tempo triplicato ?

E in questa situazione paradossale, mentre i SUSL del $pollo si sentono molto fighi per il fatto di "gestire interamente" il progetto, un programmatore serio e' una vera disgrazia sia per il $fornitore(se non fai abbastanza porcate i tempi di affitto sono piu corti, il profitto si abbassa) che per i SUSL del cliente(per loro sei sempre stato un marziano, tanto antipatico da fargli notare tutte le ca$$ate che dicono).

Basta leggere qualsiasi annuncio su $mostro_di_recruiting per vedere "ottime doti relazionali","flessibilita'","propensione al risultato" come requisiti essenziali: il resto e' opzionale, se c'e' e' visto come un bonus gratuito ma che NON DEVE interferire con i requisiti primari.

Se un programmatore non e' "addomesticato", non serve a nulla nel 99% dei casi, tanto basta "integrare" 3 librerie open-source ed il risultato si raggiunge comunque (sia chiaro: il mio tono gronda sarcasmo, ma detta dai vari SL questa frase sarebbe pronunciata con orgoglio).

 

-- Earwig

Quando hai descritto la tua carriera, ho pensato molto alla mia (io ho in più anche Delphi e sono agli inizi della sistemistica... LDAP, PDC, VMware, Zimbra, Postfix, Arca$$o)...

Sono assolutamente d'accordo con te.

Unica attenuante, se vogliamo chiamarla tale (e vale solo per i senior, non per i giovani), sono i tempi di consegna del software, che sono sempre per l'altro ieri e ti tolgono la possibilità di fare quei 2 - 300 test che ti potrebbero salvare dalla figura magrebina...

P.S. Se il gatto è ancora vivo, me lo presti?

-- Torre

Io continuo a pensare che tutto questo succede perché c'è gente che legge libri come fossero testi pieni mantra da imparare a memoria e ripetere senza accendere il cervello. Questo non ci dice nulla su quello che gli autori volevano dire (magari tanto cazzate non sono), ma ci dice tanto sul fatto che ci sono troppi supercazzolari in circolazione.

E per questo che penso che una soluzione giusta sarebbe fare una colletta e assumere Davide come killer di supercazzolari 

-- FDG

Davide... attento che questa insofferenza verso le novità con relativo rimpianto dei vecchi tempi è uno dei primi sintomi di vecchiaia... "Abbraccia il cambiamento"!  (aka: "non puoi batterli... unisciti a loro")

-- V17O

mi ricorda tanto quando mi sono rifiutato di fare modifiche ad un sito web e il cliente ha rescisso il contratto...

dopo 9 mesi è tornato con la coda tra le gambe per il macello che gli pseudoprogrammatori sostitutivi gli hanno fatto e lì l'ho sfanculizzato, stile pubblicità mastercard

-- --
Carlo

quando ho letto il titolo ho pensato che fossi intenzionato a raccontare i malanni stagionali che mi affliggono da qualche giorno -.- fortunatamente mi sbagliavo, e mi hai fatto ridere (tra un colpo di tosse e l'altro)

-- Jamin-a

resta un mistero il perchè questi programmatori vengano pagati...avranno dei bravi avvocati o dei clienti fessi...

 

stendo un velo pietoso sui nuovi metodi di programmazione...tra l'altro sta nascendo tra le nuove leve un intenso fronte anti linguaggio C e favorevole a Python ed altri linguaggi interpretati che loro continuano a dire che sono meta-compilati....

insomma sempre peggio...se penso a cosa riuscivamo a fare con un 486 e cosa invece riusciamo a fare con un quadcore 200 volte piu' potente...

-- alessio depalo

stendo un velo pietoso sui nuovi metodi di programmazione...tra l'altro sta nascendo tra le nuove leve un intenso fronte anti linguaggio C e favorevole a Python ed altri linguaggi interpretati che loro continuano a dire che sono meta-compilati...

Scrivere questo su un sito in PERL e' una chicca eh.

-- Riccardo Cagnasso

questa storia direi che è la naturale prosecuzione di "testing is for Pussy", "nerone", "la nebbia Rossa" e "ma una che funziona si puo' avere?".

Il prossimo capitolo sarà un titolo di giornale : "Sysadmin Italiano mina la diga di Amsterdam e minaccia di farla esplodere "

 

ciao BigD, tieni duro che fra poco è Natale

(non c'entra niente, ma consoliamoci con quel che passa il convento)

-- robibo

Mhhh se vuoi farti due risate io i programmi li faccio testare a mia madre invece che alla segretaria (non avendoli), che essendo una "normal-user", ovvero usa word excel e il programma di contabilità mi funge da ottimo tester (anche per l'interfaccia).

Fortunatamente stila anche un rapporto interessante sulle funzionalità

-- Francesco Belladonna

Vorrei spezzare un lancia a favore ...

.. a favore della programmazione frAGILE ...

.. a favore delle applicazioni sCUSTOMate ...

.. a favore della "forward-backward analysis" ... (uhmmm) ...

.. e vorrei spezzarle tutte sulla testa dei ProgrammaTroti!!!

-- Not So Anonymous Coward

> Ed io l'unica dimostrazione di 'agilita' che ho visto fino ad ora in tutto questo e' stata la velocita' con cui il programmatroto di cui sopra si e' eclissato dopo avermi rifilato questo mucchio di letame

Si... ma vuoi mettere con l'agilità del commerciale che l'ha piazzato? )))))

(tentando di esser serio) dove lavoro io c'era una qualche serietà (non solo da noi ma un pò in generale, fornitori compresi) fin verso il 1996-97, nel senso che anche se la ditta non è "tecnica" (lavoro in banca) aveva comunque un "reparto tecnico" che analizzava le problematiche interne, tentava di capirle e di "agganciare" i vari fornitori esterni per trovare assieme le soluzioni... questo nel passato, ed ovviamente, se il fornitore era del tipo mordi & fuggi, passavamo immediatamente alla fase due: FUGGI!!! (prima che ti morda io!).

Ora non è più così: i (wanna-be)fornitori non hanno più "tecnici" ma solo commerciali e/o call-centers (parlo ad es. di Telecom, fra gli altri, dove una volta la professionalità che ci serviva la trovavi eccome) e noi stessi, giusto per chiudere il cerchio, non abbiamo più la professionalità per valutare i nostri problemi e/o le soluzioni proposte... e siamo in balìa di questi "agiloni" (con ricadute sui costi, e quindi sulla clientela, che ti lascio immaginare).

-- Anonymous coward

> Ed io l'unica dimostrazione di 'agilita' che ho visto fino ad ora in tutto questo e' stata la velocita' con cui il programmatroto di cui sopra si e' eclissato dopo avermi rifilato questo mucchio di letame

Si... ma vuoi mettere con l'agilità del commerciale che l'ha piazzato? )))))

(tentando di esser serio) dove lavoro io c'era una qualche serietà (non solo da noi ma un pò in generale, fornitori compresi) fin verso il 1996-97, nel senso che anche se la ditta non è "tecnica" (lavoro in banca) aveva comunque un "reparto tecnico" che analizzava le problematiche interne, tentava di capirle e di "agganciare" i vari fornitori esterni per trovare assieme le soluzioni... questo nel passato, ed ovviamente, se il fornitore era del tipo mordi & fuggi, passavamo immediatamente alla fase due: FUGGI!!! (prima che ti morda io!).

Ora non è più così: i (wanna-be)fornitori non hanno più "tecnici" ma solo commerciali e/o call-centers (parlo ad es. di Telecom, fra gli altri, dove una volta la professionalità che ci serviva la trovavi eccome) e noi stessi, giusto per chiudere il cerchio, non abbiamo più la professionalità per valutare i nostri problemi e/o le soluzioni proposte... e siamo in balìa di questi "agiloni" (con ricadute sui costi, e quindi sulla clientela, che ti lascio immaginare).

 

Stessa tipologia di azienda...

Stessa sensazione...

Mi sa che abbiamo fornitori comuni mio caro Anonymous coward...

-- Eremita Solitario

Dunque io non sono mai stato veramente un programmatore,

Ok, i miei programmini sul C64 li ho scritti (e venduti) anche io, anche se a casa  non avevo neppure lo strafighissimo (??) floppy drive per svilupparli, tutto scritto in base ad una copia (ovviamente) fotocopiata del manuale e testato direttamente dal cliente ... Poi forte dei miei studi di pivello perito industriale informatico, ho fatto danni anche con qualche assembler, col C (senza i più), col DBIII, col Clipper, con il primissimo Acce$$ ... ma quando mi sono lanciato dal trafficonismo ad in una cariera (quasi) professionale ho scelto più o meno scentemente di non programmare, dato che non mi è mai andato a genio di scrivere codice "a comando" e "sotto padrone" .... lo so, ero molto giovane, verde e stupido, ma così è andata

In questo momento, dopo essere passato attraverso l' "amministrazione" non dico quanti diversi SO e reti mi ritrovo a fare il "sistemista di prodotto" ossia sono il pirla che riceve il codice e la documentazione (burocratica) che lo sviluppo spurg ... scusate produce e che la installa negli ambienti di produzione. Insomma dopo decine di anni di professione sono finalmente diventato un installatore ...

Ed i programmatori, sono gli stessi dappertutto: anche nella grossa struttura in cui lavoro, che ha una foxxuta regola e procedura per tutto, dove tutto il lavoro (e parlo solo dell'installazione e quindi dell'installabilità) dovrebbe essere noto a tutti e le regole chiare e documentate ... non ti dico le cavolate che succedono.

I maledetti hanno (dovrebbero avere) ben due ambienti prima dei nostri (svilupo e test) dove fare le loro maledette cavolate e prove ma arrivano sempre a farsi spiegare cosa scrivere da noi del collaudo/produzione. E questo quando va bene, perchè una buona percentuale (stimo un 20% circa) in realtà specie per le modifiche minori / patch non sviluppa per nulla.

Semplicemente ci mandano una serie di "versioni" che correggono in base alle anomalie di installazione che segnaliamo. Ognuno di questi ri-cicli e di queste anomalie ha un costo (interno) che in un modo bizzantino viene poi ricaricato sul gruppo di sviluppo, ma evidentemente sviluppare appoggiandosi all'ambiente di collaudo (dove in teoria tutto dovrebbe già andare, a meno di qualche dettaglio di installazione) costa meno che tenersi quache programmatore che sappia scrivere e/o manutenere il loro foxxuto codice. 

La noia e la nausea infinita di questi che ri-ciclano in collaudo per 10-15 volte o anche più, non credo di potervela spiegare, basti dire che ogni ri-ciclo comporta a me personalmente che lo gestisco (o a qualche altro collega) un numero infinto di mail, click forsennati sugli appositi applicativi per la gestione dei ricicli, telefonate, discussioni ecc ecc .... più che installatore sono un foxxuto burocrate, ecco che mestiere faccio adesso.

Il massimo assoluto si raggiunge quando quache testa di uovo decide che per quella particolare applicazione si deve usare un prodotto scritto in toto da una ditta esterna, che ovviamente sviluppa a standar suo (spesso abbastanza nullo) ed il lavoro da fare è "solo" farlo funzionare nell'infrastruttura ... il tutto affidato ad un qualche UL che acchiappa il primo sotto-frogammatore che gli capita tra le mani e lo tartassa chiedendo solo "risultati" e "tempi di conosegna" senza conoscere un ca$$0 ne di programmazione, ne dei req

-- Davide A

ehm .... credo di avere premuto un OK di troppo nel post precedente ... ok, sono un CL anche io, a volte.

dicevo senza sapere un ca$$0 ne di programmazione ne dei requisiti di tutta la struttura che deve ospitare il "coso" ... In questi casi, dato che nulla funziona ne può funzionare, partono le telefonate a livello di dirigenza (dove risulta che noi del collaudo siamo dei cretini ostli) ed alla fine il nostro capo ci fa capire (ovviamente senza dirlo mai apertamente) che è meglio fargli fare quello che vogliono con i tempi che vogliono .... ed un'altra petroliera di liquame passa in produzione

Quindi anche nei "grossi centri informatici di valenza istituzionale" (tm) il programmatore sa sempre di trota e gli UL emanano sempre le medesime piacevoli profumazioni di fiori di vacca, tanto quelli che le respirano sono sempre i "baracchini" che lavorano vicino alle macchine e che in un modo o nell'altro, alla fine, fanno funzionare le cose.

-- Davide A