Newsgroup: it.lavoro.informatica
Titolo: Poste in profondo rosso !

Dice che in poste un batch notturno abbia scambiato 600 euro per
60.000 euro e che tutti i conti siano andati in rosso..
Se è vero.. è favolosa. Qualcuno ne sa niente ??


Ecco qua: 
http://www.corriere.it/cronache/09_novembre_25/poste-salta-virgola_25bcc5e6-d9b7-11de-a7cd-00144f02aabc.shtml
Salta la virgola, sballano i conti
del Postamat. Inibiti i prelievi
Per un'anomalia contabile alcune transazioni «potrebbero aver generato
addebiti superiori a quelli effettivi»

 60.000 euro e che tutti i conti siano andati in rosso..
Non era un appalto di rootkit? :-PPP 
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 addebiti superiori a quelli effettivi�
Prima il sito che � stato bucato, ora questo...quando capiranno (loro e
tutti gli altri) che per avere un'infrastruttura informatica decente
devono SBORSARE e assumere gente con le palle invece dei soliti
incompetenti 
co.co.de
, riciclati nel settore informatico dopo aver
abbandonato un corso di laurea in lettere o in filosofia, pescati da
un'agenzia interinale o da un bodirentallaro? Vabbe'...era una domanda
retorica...

System Failure ha scritto:


se produci troppo troveranno il modo per segarti.Sai com'�...la gelosia
degli (in)utili idioti � devastante.
-- 
cambFORZAJ...@liVIVAMILANbero.it
togli le due bestemmie per scrivermi.
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 degli (in)utili idioti � devastante.
Guarda, il paradosso sta nel fatto che io (scusa se devio il discorso
sul piano personale) non produco "troppo", il mio codice � breve,
conciso e con i commenti e la documentazione annessa che arrivano al
(forse, non ho mai contato) totale di 5-15% di tutto il progetto (e no,
la documentazione non � prolissa, � giusta, � il codice che tendo a
farlo non-prolisso e non-"bloatato"). Solo che il mio modo di lavorare �
cos� che spesso faccio incazzare i pointy-haired manager, ai quali
qualcuno ha infilato nella scatola cranica l'idea della programmazione
"Agile" (della quale non hanno capito una mazza tranne che il codice si
fa subito e che si "risparmia tempo e soldi" saltando la fase
dell'analisi e della scrittura di qualsivoglia documentazione), ai quali
piace contare ogni giorno le righe di codice fatte dai dattilografi
informatici: Ci metto pi� tempo a definire le specifiche che
programmare. Spesso passano settimane, a volte mesi, prima che io scriva
una sola riga di codice. Poi ci metto di solito pocchissimo tempo a
sviluppare. E la documentazione sul progetto e sui test fatti serve
prima di tutto a *ME* perch� serve come prova per pararmi il culo (e per
scaricare il barile a chi di dovere) nel caso di problemi. Vedendo i due
disastri con l'infrastruttura informatica delle poste, vogliamo
scommettere che quelli lavorano in modo "Extreme Agile" (l'ho coniato
ora il termine): senza alcuna documentazione dell'archittettura e dei
test, senza definire i compiti precisi da assegnare agli sviluppatori,
ai tester, ai PM, ecc? Di conseguenza dubito che ora potranno pescare i
colpevoli, e dubito che qualche testa cadr�. Mi piacerebbe essere
smentito, ma questa � la mia opinione.

System Failure ha scritto:


se produci troppo troveranno il modo per segarti.Sai com'�...la gelosia
degli (in)utili idioti � devastante.
-- 


 smentito, ma questa � la mia opinione.
Di teste non ne possono cadere per il semplice motivo che se devono cadere
cadono teste di consulenti.
E a quanto mi dicono la dentro di consulenti ne sono rimasti verametne
pochi.
Ci sono solo ufficiali e sotto ufficiali.La truppa � ridotta ad uno
sparuto gruppo di sottopagati cocod�.


System Failure ha scritto:

oh ma guarda concordo al 100% anche io questa metodi iper-agili dove si
inizia a programmare su progetto che cambia in corso d'opera (per essere
super flessibili) mi sembra una grande puttanata, c'� poca
pianificazione, e le boiate vengono fuori, io avevo sempre rispettato la
regola del 40-30-30  ossia un 40% per la progettazione, un 30 per
scrivere codice un 30% per testare il tutto.
Da maggio sono con un "TEAM" su un progetto con metodologia "AGILE" nato
da alcuni "SCAFFOLD" costruiti su un db (per altro db con strutture a
cazzo perch� non c'� stata la dovuta progettazione iniziale) e con
specifiche che cambiano e aumentano ogni quindici giorni e su cui
continuamente sono state fatte modifiche.... il risultato... una bella
merda a livello di codice.

 merda a livello di codice.
mi spiace per il casino in cui ti ritrovi,  ma quello *NON E'*
applicare un processo di sviluppo agile. Il termine accademicamente
corretto e' "Programming Ad Minchiam"..o come dice un mio caro collega
"programmare alla pizzaiuola"
Come e' possibile scrivere codice che fa schifo in qualsiasi
linguaggio e' possibile creare caos e disastri seguendo qualsiasi
metodo..
Linguaggi, piattaforme tecnologiche e metodologie sono strumenti. In
mano ad una banda di cazzoni anche lo strumento piu' utile ed elegante
aiuta solo a fare dei danni.

 merda a livello di codice.
A parte che io non ho mai visto un codice che sia uno che come risultato
finale non fosse "una bella merda", indipendentemente dal fatto che il
metodo fosse agile o meno, vorrei capire come faresti a gestire un
progetto per il quale una delle specifiche e':
"le richieste del cliente (e quindi le specifiche) cambieranno ogni 15
giorni".
Ciao,
Marco
-- 


 wrote:

A me è successo un botto di tempo fa il contrario.
Avevo un conto postale (o quello che erano visto che parlo degli
ultimi anni 80) con sopra qcosa come 300.000 lire... mia madre fa un
estratto conto e... 30.000.000 di lire!!! Nemmeno il tempo di tornare
in posta che la cosa era già stata sistemata...
Al3x


E' facile, gli si vende come soluzione sw visual studio, dicendogli che in 
questo modo avr� sul serio piena autonomia nell'inseguire le proprie 
specifiche con la dinamicit� che pi� gli aggrada, senza parlare delle 
personalizzazioni che potranno essere infinite e a qualsiasi livello! :-)
Anzi, anche senza ridere, visto che alla fine � davvero l'unica cosa sensata 
da fare in certi casi per far capire quanto l'ostacolo alla soluzione non 
sia la parte it, ma tutto quello che viene moooolto ben prima.

 
a meno che non siano richieste banali non ci sarebbe nemmeno il tempo in
15 giorni di doverci fare tutti i test del caso. (inclusi quelli
pratici, gi� per il bilanciatore prendiamo ad esame una settimana di
statistiche per decidere su quale batteria di server va)

 definire le specifiche che programmare.
Condivido totalmente. E mi sento di dare alcune perle di lucapensiero.
Nota, non � che siano cose che mi sono inventato o che mi sono scese
dal cielo a mo di spirito santo e che dispenso ai mortali.
Semplicemente, ho rubacchiato qua e la...
Prima regola. Se puoi isolare, isola. Se hai due routine che fanno
grossomodo la stessa cosa, cerca di ricavare dalle due una sola. Se
dovrai metterci le mani, sarai molto pi� rapido e sicuro (anche se
potrai fatturare meno righe... ;-)). Senza contare che i test che farai
otranno essere pi� efficienti.
Seconda regola. Documenta. Non � necessario un documento word, bastano
due parole, ma per quanto corta sia una routine, se chi poi la legge
(anche tu!) ha idea grossomodo di quel che fa al primo sguardo, meglio!
Terza regola. Sii conciso. Una funzione che supera le 60 righe
probabilmente ha qualcosa che non va. Sicuro che andasse scritta cos�?
Quarta regola. Pensa prima di buttare gi� codice. Quante volte (almeno
a me) � capitato di lavorare un paio d'ore per scoprire che la strada
pi� semplice era altra e che ci avrei messo globalmente molto meno
partendo col piede giusto?
Quinto. L'OOP � tua amica. Se hai a che fare con un linguaggio che la
supporta, caspita, usala! (questa perch� c'� ancora gente, magari con
passato di VBista, che fa fatica a usare in modo opportuno le classi).
Poi, se me ne vengono in mente altre, aggiunger�... :-D
-- 
Ciao!
Luca

 giorni".
Prima di tutto progetti cos� non li accetto. Si trovino (che ce ne sono
gi� troppi) di sfigati che lo accettano, io mi posso e voglio permettere
(per ora, quando non potr�, cambier� settore) la scelta, ovvero i
progetti troppo merdosi non li accetto.
Poi, secondo te, che canti cos� tante lodi all'"Agile", quando le
specifiche non esistono e la confusione regna sovrana nelle teste dei
committenti, la soluzione non � cercare di chiarire la cosa, mettersi
con loro e aiutarli a definire bene il progetto, ovvero di definire bene
le cose prima di darle in pasto ai programmatori, ma la soluzione
sarebbe propagare il "caos primordiale" dal commitente fino agli
sviluppatori con un continuo feedback di confusioni? Bella scelta. Poi
non meravigliamoci se le cose vanno cos� come vanno. E aggiungo: Non �
il problema come qui di solito si dice, che chi accetta il lavoro
sottopagato danneggia il settore. Il settore danneggiano soprattutto i
consulenti non-consulenti, che invece di aiutare al cliente a dare la
forma informatica alle idee che lui non sa definire in modo informatico,
accettano il caos e ci marciano sopra. Ecco perch� i clienti sono
incazzati e perche chiudono i portafogli.

 essere super flessibili) mi sembra una grande puttanata
Ecco, qui son d'accordo. In base a quel che ho studiato, non � che il
fatto che i rilasci siano molto ravvicinati e per funzionalit� escluda
la necessit� di usare la testa prima delle mani...
-- 
Ciao!
Luca

 corretto e' "Programming Ad Minchiam"
Caro collega, mi consenta di correggerla.
La definizione corretta � "Programmatio ad minchiam". Che vuole, gli
anglofoni storpiano tutto... :-DDD
-- 
Ciao!
Luca

 > 15 giorni".
Beh, video illuminante in proposito:
http://www.youtube.com/watch?v=JWPYxu1PKKg
Aggiungo e rettifico. Cambino pure le specifiche, basta che paghino a
ogni rilascio (flessibile si, 'mona' no).
-- 
Ciao!
Luca

 super flessibili) mi sembra una grande puttanata,
Questo cosa c'entra con l'agile, di grazia?
-- 
Vide

 merda a livello di codice.
Sicuro che si possa definire Agile quella roba? Agile non � buttare gi�
codice come capita su specifiche instabili come la nitroglicerina
sperando che poi alla fine quando metti insieme i pezzi tutto
magicamente funzioni... quello non � Agile, � frAgile :D
Poi oh, dipender� anche dalle dimensioni e dal tipo di progetto. Per
quel che mi riguarda (web development) io mi ci trovo bene.
-- 
MySQL and PHP are popular not because of their quality, but despite it.

 aiuta solo a fare dei danni.
In generale concordo. Anche se la capacità di limitare le  fesserie è
certamente una misura della validità dello strumento o metodo.
Atrimenti, siamo tutti buoni ad inventarci il metodo, e poi di fronte
ai bachi a dire: eh, ma l'hanno usato male!

 codice mi sveglio...
Ricorda. Far sottoscrivere un documento di analisi ad un cliente, e
saperlo far rispettare, non è da tutti.
Ne ho visti molti che non sono in grado di fare nè l'una cosa nè
l'altra. Ma credimi  non è affatto impossibile.
Anche nell'IT c'è una scala di capacità, checchè se ne dica.

 quel che mi riguarda (web development) io mi ci trovo bene.
Se sono agili o meno non lo so, ma certo è che usare quella
metodologia per un sistema bancario è da folli. Quasi come usare il
waterfall per i siti web.

 waterfall per i siti web.
...se non sono siti bancari. :-D

 ai bachi a dire: eh, ma l'hanno usato male!
Oppure "Sono stato frainteso" (cit.). :-D

corretto e' "Programming Ad Minchiam"..o come dice un mio caro collega
Detto anche PDS (Pene di segugio)
Stef 

 poi sono cazzi della programmazione rientrare nei tempi.
Ma anche qui, un bravo tecnico sa farsi rispettare dal commerciale,
oltre che dal cliente.
Ed anche questo non è da tutti.
La bravura nell'IT non è solo sapere bene Java piuttosto che il C#.

 Vabbe'...era una domanda retorica...
in effetti, avevo quasi pensato di telefonare anch'io, ma ho lasciato 
perdere ....
Andrea 

 Ha detto veramente 'ragazzo' ...
Vabbe, dai, gli idioti ci sono in qualsiasi categoria. Se penso pero' a
quanto e costato... Due conti della serva? con 20 milioni milioni di
euro paghi  50 persone per 10 anni. Parlo di 40.000 EUR/anno lordi di
media; volendo, che non credo che per fare Italia.it ci vogliano 50
persone per 10 anni, diciamo che ne paghi 30 di piu. Cio che ti resta
fuori sono i costi di struttura, ma ne fai di roba con 10 milioni di
Euro... Bene, io sono arrivato a 30 milioni, ne erano stati stanziati
50!
-- 
Ciao!
Luca

 50!
So che hai fatto una riflessione retorica, i 20 milioni di euro che non
trovi sono quelli pi� inmportanti, servono alla "lubrificazione" del
processo di business, affinch� tutti gli "ingranaggi" non subiscano
rallentamenti.
La vuoi far girare questa economia oppure no ? :-P
PaF

 PaF
Andrea 

 merda a livello di codice.
Senza dettagli pare che il PM non sappia gestire il cliente, basta
quindi dirgli che il prodotto avrà difetti anche gravi sotto tutti i
punti di vista se non è in grado di guidarlo. Se usi SCRUM (come pare)
e i maiali non sono uniti, è proprio inutile anche cominciare lo
sviluppo.
  ngw

 commerciale, hai voglia di essere bravo...
Mah, inutile lamentarsi che mancano i documenti di analisi firmati e
concordati, se neppure ci si prova a scriverli, e se neppure ci si
prova a discutere con il commerciale, cliente, capo, ecc.
Oppure se neppure si prova a discutere i continui cambiamenti, se uno
è semplice sviluppatore/esecutore.
Non poche volte, invece, ho notato questo atteggiamento rinunciatario.

 probabilmente ha qualcosa che non va. Sicuro che andasse scritta così?
Mi ritorna in mente una funzione di 3500 riga sviluppata in offshore
(India) senza unit test, ogni volta che c'era da metterci mano c'era
il fuggi fuggi generale :))
--
ale
http://ale.riolo.co.uk

 La cosa che dispiace � che comunque il sito non � stato fatto :-(
Questo � un dettaglio implementativo, l'importante � far girare l'economia
:-P
PaF

 :-P
Tu hai messo una specie di faccina, ma la mia esperienza degli ultimi
8 anni dice che la cosa che hai scritto costituisce nient'altro
che la pura e semplice realta'.
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 progetti troppo merdosi non li accetto.
Perch�, a te sono tanto gentili ed onesti da dirlo PRIMA che cambieranno
le specifiche ogni 15 giorni? O te lo dicono mica DOPO che hai accettato?

 incazzati e perche chiudono i portafogli.
Qui invece mi permetto di dire che questa cosa di  cui sopra e' una
grandissima cazzata, perche' sia io personalmente per molti anni, sia
altri hanno tentato e tentano di spiegare a moldi dirigenti aziendali (e
di aziende non piccole) che ad esempio valutare un progetto informatico in
termini di ore-uomo e' una immane cazzata, cosi' come fare l'assunzione
che 
"se un programmatore ti puo' consegnare un progetto in 6 mesi, allora 6
programmatori ti possono consegnare lo stesso progetto in 1 mese" � una
immane cazzata. 
Esempio concredo:
Luogo: Roma, via Anagnina 203.
Azienda Ericsson Telecomunicazioni Spa
Anno: 2004 (o forse primi mesi del 2005).
Progetto: uno dei suddetti progetti per la "strong authentication". 
Programmatori: Io (senior) e un mio collega (junior). Entrambi esterni 
"Solution Architect": un dipendete Ericsson.
Il Solution Architect mi viene a chiedere , quanto tempo ci vuole per fare
un certo software. 
Gli dico un mese. 
Dopo 15 giorni arriva il "Solution Architect" e mi dice: "dov'e' il
software ?". 
Io gli dico che gli avevo detto che ci voleva un mese e sono passati 15
giorni. Lui dice che se gli ho detto 30 giorni , poiche' eravamo 2 persone
dovevo consegnargli il software dopo 15 giorni [15x2=30].
All' "ALL Staff meeting" (o forse ad un' altra riunione piu' ristretta,
ora non ricordo esattamente) un dirigente ci spiega che la
"modernizzazione" di Ericsson rispetto a qualche anno prima prevede che si
adotti la formula seguente
T=E/n
dove T e' il lead time per la consegna di un progetto (software o altro
non importa) 
E = effort
n= numero di risorse che lavorano a quel software.
La formula sopra riportata viene considerata "fortemente innovativa"
dall'azienda.
La formula (insieme ad altre cavolate simili) viene illustrata
con tanto di slide (c'e' gente che ha anche perso del tempo ad
inventarsela).
Quindi, quando qualcuno del marketing o degli Architetti "di sistema"
chiedono ai tecnici quanto tempo ci vuole, questi ultimi (i tecnici) devono
tenere conto che vale la formula sopra.
Al mio "responsabile" che era direttamente "sotto" il suddetto dirigente,
ho fatto presente che qualsiasi libro di ingegneria del software riporta
che se un programmatore in un giorno produce 100, 10 programmatori in un
giorno producono al massimo 300 e che quindi, la formula sopra riportata
e' palesemente errata.
Risultati: 
risultato 1: io da fine 2006 non lavoro piu' in Ericsson
risultato 2: Il dirigente sopra citato e il mio responsabile sopra citato
immagino che lavorino ancora in Ericsson (fino ad aprile di quest'anno il
secondo ci lavorava di sicuro)
risultato 3: Ericsson adotta ancora la formula sopra riportata
risultato 4: Tutte le aziende dove sono stato dopo Ericsson
(sostanzialmente due o tre) usano piu' o meno la formula suddetta, anche
se magari con alcune varianti.
Ne segue che l'implicazione
"i clienti sono incazzati e chiudono i portafogli" perche'
"i consulenti non-consulenti, che invece di aiutare al cliente a dare la
 forma informatica alle idee che lui non sa definire in modo informatico,
 accettano il caos e ci marciano sopra."
e' palesemente una cazzata.
Ciao,
Marco.


 sia la parte it, ma tutto quello che viene moooolto ben prima.
Effettivamente, senza ridere, quello che tu dici e' una specie di
"riassunto" di quello che e' avvenuto dal 2003 in poi. Ovvero il cliente
(Tim all'epoca) ha cominciato a dire: "o segui le mie indicazioni
(leggasi: o mi permetti di cambiare specifiche, bugdet e quant'altro come
e quando mi pare) o ciccia".
E i fornitori, anche se grandi (come Ericsson) hanno deciso di adeguarsi,
propinando la stesa solfa a loro volta ai loro fornitori (sia
bodyrentallari [in questo caso non pesa tanto cambiare le specifiche
quanto cambiare il budget] sia fornitori di ben altro livello, tipo HP).
Ciao,
Marco


 
http://www.youtube.com/watch?v=JWPYxu1PKKg
Se e' tratto da PyCon3 (o anche da PyCon1, ma non credo), io c'ero!
Se e' tratto da PyCon2 invece l'avevo solo gia' visto on-line.
E' che ora faccio fatica a distinguere quello che ho visto "on-line" da
quello che ho visto "live".
Ciao,
Marco.


Il Fri, 27 Nov 2009 11:02:19 +0100, Marcoxxx ha scritto:
[cut]
Mi permetto di aggiungere solo una postilla: quanto da te enunciato pu�
valere per i grossi gruppi pachidermici, ma per il cliente medio/piccolo
(parlo di aziende tra i 30 e 100 dipendenti) un consulente che sa dare
consigli e aiuta a plasmare le idee del responsabile di turno � importante
e valutato positivamente. 
Questo nella mia personale esperienza. 
PaF