Newsgroup: it.lavoro.informatica
Titolo: manutenzione del software pratica obsoleta!

Ultimamente sto facendo modifiche a un applicativo desktop del 
1994/1995, mai in vita mia ho sviluppato cosi' a basso livello, nel 
senso di codice schifido non di assembly! :-D
Devo incastrare delle robe in procedure staticissime del tipo che 
siccome devo perderci poco tempo non posso rifare il sistema di log ma 
ci devo incastrare della roba a suon di martellate! :-(
Oppure c'e' un componente drag and drop ipercomplesso che all'epoca era 
un miracolo ma adesso fa schifo e rimane li' perche' per farlo ci hanno 
messo tipo 8 mesi, quando ci devo mettere le mani per fare una modifica 
il giorno dopo devo andare dallo psicologo!!! -_-
Ma secondo voi attualmente ha senso "mantere" il software? Per me e' 
tutta fatica sprecata va bene un po' di bug fix per un po' di anni ma mi 
pare una cazzata forzarci una miriade di modifiche alla fine ci si mette 
piu' tempo e si rischia di peggiorarlo... naturalmente l'azienda pensa 
che per arrivare a quel livello li' ha speso tantissimo e non si sogna 
nemmeno di rifare tutto!boh!
C'e' qualcuno qui a cui capita ogni tanto di fare manutenzione di 
sofware antiquati?
-- 
http://www.evilripper.net
http://www.flickr.com/photos/evilripper/

 Ma secondo voi attualmente ha senso "mantere" il software? 
mi pare che non abbia senso la domanda, almeno posta in questi termini.
la manutenzione ha un costo, il rifacimento un altro. e se anche alla 
lunga il costo manutenzione supera quello di rifacimento viene spalmato 
su più esercizi (le aziende chiudono il bilancio annualmente). quindi non 
solo ha senso in senso lato mantenere il software, ma può essere anche 
una scelta necessaria.
il punto è che ogni caso va valutato a se. per questo ti dico che la tua 
domanda posta in quei termini non ha senso.

 su più esercizi (le aziende chiudono il bilancio annualmente).
La manutenzione continuativa ha un costo fisso che un'azienda se lo 
porta dietro per anni,io sono dell'idea che se si fa un progetto lo si 
finisce finisce li'. Cioe' manutenzione si ma solo sui bug, che porta 
via molto meno tempo rispetto a inserire nuove funzionalita'!! Se e' 
possibile nel nuovo progetto si possono riutilizzare alcuni componenti 
e' logico riutilizzarli...
imho volevo solo dire che mantenere un software per 15 anni ha dei costi 
enormi e alla fine, questo software ha un database orrido e con 
millemila robe tutte raffazzonate! :-D

 il giorno dopo devo andare dallo psicologo!!! -_-
Non ho capito, sta lì perché serve o perché ci hanno messo otto mesi?
Se non serve e/o può sostituire con qualcosa scritto bene in tempi
ragionevolmente brevi, chi se ne frega se ci hanno messo otto mesi od
otto anni per farlo?

 otto anni per farlo?
ma infatti!! chissenefrega se ci hanno messo del tempo!! :-(
boh!!!!

 sofware antiquati?
Per me qualsiasi software senza unit test e senza automatic build
integration è antiquato (e se lavorassi nel QA, qualsiasi software
senza system test automatici sarebbe antiquato).
--
ale
http://ale.riolo.co.uk

 sofware antiquati?
In ambienti dove il software è costato centinaia di migliaia di euro,
la manutenzione è cosa quotidiana.

 sofware antiquati?
presente :-) o meglio :-(
Software in c++ anzi meglio in C, iniziato a scrivere negli anni 80->
porting da Cobol -> interfaccia in Vb6. Automazione di depositi.
Quando a Luglio scorso ho chiuso il contratto le mie finanze ne hanno 
perso ma la mia salute mentale ne ha guadagnato.
Software in jsp/javabeans/mysql su Tomcat, scritto negli anni 90.
Peccato che i Javabeans siano inclusi ma non usati..peccato che ci sia 
il 50% del codice ripetuto. 
Questo cliente si è però convinto a una riscrittura con Asp.Net MVC!!! 
-- 
Cordiali saluti
Davide
Consulenza Informatica
 a Monza e Brianza 
www.cleosolutions.com
Siti amici
Consulenza fiscale? 
http://tiny.cc/8UbTn

 
ma non era meglio un qualsiasi framework mvc java allora? che magari del
codice pure lo riutilizzavi. (e oltretutto sei indipendente
dall'architettura del server, ovvero le specifiche di jee sono pubbliche
e esistono diversi application server che le implementano in maniera più
o meno degna, lasciando perdere il fatto che con 
asp.net
 mvc sei
vincolato a iis visto che mono su 
asp.net
 è proprio carente.)

 antiquati?
Ogni tanto? diciamo 8 ore al giorno 5 giorni a settimana.
Che vomito.

sofware antiquati?
ho "ereditato" parte della clientela di mio padre (che lavora(va) su
sistemi as/400 e 38 e 36 e 34 dell'IBM) in questi ultimi 10 anni parte
li ho convinti, parte hanno avuto la necessità, di riscrivere quei
software, cmq proprio in questi giorni sto scrivendo un'applicazione
che re-ingengnerizza de-facto un'applicativo scritto nel 1985, la cui
seconda release risale al 1992 e l'ultimo ritocco al 1998


facciamo anche 9 ore a volte (ma meno male soltanto un paio di giorni la
settimana)
roba scritta in php3, perl e vb6
ognuno ha le sue disgrazie!

 ma non era meglio un qualsiasi framework mvc java allora? che magari del
In quest'ordine:
1)Eclipse non mi piace.
2)NetBeans è troppo schizzinoso.
3)Java è più scomodo (più che altro le informazioni sono disperse in 
mille rivoli) e i messaggi di errore sono meno intuitivi.
Quando leggo della documentazione Java mi viene l'orticaria, le prime 
pagine mi devono convincere di quanto è figo invece di dirmi 
semplicemente quello che mi serve.
4)Per Java manca una guida (come microsoft per c#), qualcuno che dice le 
cose si fanno così e poi funzionano.
5)Esistono 4k framework diversi per java, peccato che spesso la 
documentazione sia carente quando c'è.
6)Dell'indipendenza dal S.O. non me ne curo, lavoro con aziende
che spesso hanno già i server Windows a disposizione.
7)Mi trovo meglio con C# e, IMHO, rende lo sviluppatore più produttivo.
8)Ho le mie librerie in C# ampiamente riutilizzabili.


 ognuno ha le sue disgrazie!
si ma e' una tortura cazzarola!!

 seconda release risale al 1992 e l'ultimo ritocco al 1998
Sarebbe interessante conoscere esperienze di questo tipo, le 
problematiche, i successi e gli insuccessi, le motivazioni, le 
aspettative dei clienti e l'analisi della soddisfazione post-consegna. 
In particolare, vengono usati dei tool di conversione o di emulazione o 
vengono totalmente riscritti ?
Personalmente ho una unica applicazione "grande" ancora in uso ed è 
text-based, essendo il suo sviluppo iniziato nel 1987... mi hanno 
chiesto se era possibile trasformarla in applicazione GUI mantenendone 
lo stesso impianto visivo e di interazione... cosa che è, per come è 
imopstata l'applicazione, praticamente impossibile...
Quindi oltre al costo di una ri-analisi delle procedure, con sfoltimento 
delle funzioni obsolete, porting o riscrittura del codice, possibile 
conversione delle basi dati, periodo di debug, gestione del parallelo 
(ove possibile) etc occorre inserire anche il costo per la produzione 
della nuova documentazione e per l'aggiornamento del personale...
Magari sarà pure tutto carino a video... ma poi occorre dimostrare coi 
fatti che il porting renda l'uso più facile e veloce, che lo renda uno 
strumento in grado di rispondere meglio alle esigenze dell'utente e 
della ditta....

 Comunque ritengo che tu abbia programmato poco con Java.
sicuramente ho avuto più esperienze su tecnologie microsoft.
Ho lavorato con java dallo 1.0 e la documentazione è rimasta con la 
stessa logica che non trovo piacevole.
Il problema, di chi deve lavorare tutti i giorni, è sempre lo stesso non 
puoi stare a guardare ogni nuovo framework che qualcuno si inventa.
A volte le problematiche sono di diverso tipo e quando usi tecnologie 
OPEN ci sono troppi punti di vista.
Ho lavorato su un Adempiere per circa 2 anni, mai visto un progetto che 
ti fa pagare la documentazione.
Poi sono dell'idea che io compro Visual studio ed MSDN, e la 
documentazione la devo trovare da una fonte sola ed autorevole.


 si ma e' una tortura cazzarola!!
Una delle varie nel buco di merda in cui lavoro. 

 via molto meno tempo rispetto a inserire nuove funzionalita'!! 
Sul resto sarei anche d'accordo. Su quest'ultima affermazione invece, mi
viene da pensare che tu non abbia mai avuto come "committente finale"
qualcuno tipo Tim/Telecom/Poste Italiane o simili.
In altre parole... nuova funzionalita' si inserisce se committente chiede
di inserirla (e se "committente" e' uno di quelli che ho indicato sopra,
stai sicuro che ogni 15 giorni c'e' una funzionalit'a nuova da inserire
(quando non ci sono funzionalita' nuove da inserire => programmatore a
casa) 
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 della ditta....
Verissimo. Da noi il precedente sistema Cobol aveva almeno un 50% di
programmi batch. Il tutto è stato migrato, o meglio riscritto
manualmente, in Java. L'unica miglioria che il cliente finale potrebbe
vedere nei batch è un'eventuale maggiore rapidità nella consegna ed
efficienza nello sviluppo. Che non c'è, perchè i batch non sono il
punto forte di Java..... Ergo, un 50% della migrazione si poteva
evitare tranquillamente.

 casa)
certo dipende dal progetto, non l'avevo detto prima ci sono casi in cui 
se e' molto grande, oppure se lo sviluppano da soli son daccordo sul 
modificarlo tanto ne esiste uno solo, invece ho notato che ci sono molte 
aziende IT che hanno tipo 2 o 3 software di cui fanno manutenzione.
Magari hanno migliaia di clienti che pagano un canone mensile e che 
hanno sempre lo stesso software da 20 anni con database decrepiti!! :D
E i programmatori stanno li' ad aggiungere nuove funzionalita', 
modifiche e poi succede come a jenga che vien giu' tutto!! :-D
Attualmente ci sono dei sistemi che permetterebbero di creare dei nuovi 
progetti che funzionerebbero 1000 volte meglio e con meno buchi.
sembra che preferiscano "mantenere" cio' che si ha e non fare cose nuove...
IMHO per progetti medi si dovrebbe fare bug fix di quello che c'e' gia' 
e poi si tengono occupati i programmatori a farne uno nuovo migliore con 
piu' funzionalita' comprendendo al momento della progettazione le 
(magari dopo aver raccolto i feedback dei clienti), uscendo magari ogni 
2 anni con un software ex-novo!
Oltretutto questo sistema e' obsoleto ormai sembrano tutti andare verso 
il clouds, qua in ita ci sono ancora una miriade di software
client-server gestionali!! :-D

 vengono totalmente riscritti ?
Non so se sia esattamente quello che intendi ma a me nel 1999-2000 capito'
di fare una specie di "esportazione sul web" dei dati di un AS400. 
Erano dati di un calzaturificio. Sul Web si mostrava una specie di
catalogo delle calzature suddivise in lotti e mostrate a seconda del tipo
di pellame e colore in cui erano realizzate. Il catalogo era accedibile
dai rappresentanti che, quando andavano dai clienti, potevano
mostrare tale catalogo e prendere eventuali ordini di un certo numero
di lotti.
In realta' non e' che fu modificata l'applicazione su AS400. 
L'applicazione resto' sempre la stessa, solo che i dati venivano presi
giornalmente da AS400, trasferiti su un server Linux e da qui esportati
sul Web tramite Zope.
Su Linux c'era un DB reingegnerizzato rispetto a quello di AS400
Tanto per intenderci: i dati che arrivavano da AS 400 consistevano
sostanzialmente di 1 sola tabella in cui c'erano 120 campi perche' 
ad esempio se il modello individuato dal codice 12345 poteva essere
realizzato in cuoio e in pelle vacchetta e magari se era relizzato in
cuoio poteva essere di colore nero o blu mentre se era realizzato in
vacchetta poteva essere nero o rosso, allora nella riga individuata dal
codce
12345 c'erano, tra gli altri, dei campi contenenti i seguenti valori:
cuo_ner
cuo_blu
vac_ner
vac_ros
e cosi' via per tutti gli altri tipi di pellame e colore in cui si poteva
realizzare quel modello.
Poi ovviamente se il modello 12346 (diverso dal precedente) poteva essere
realizzato solo in cuoio, allora nei campi in cui nella riga precedente
c'erano i valori vac_ner e vac_ros, nella riga corrispondente a 12346
c'erano dei null.
E magari se il modello 12346 poteva essere solo bianco => ecco che si
aggiungeva un altro campo contenente il valore 
cuo_bia
In altre parole: c'era 1 campo per ogni possibile combinazione
pellame-colore in cui era possibile realizzare almeno 1 tipo di calzatura.
E altre cose simili.
La realizzazione di questa esportazione sul web dei dati del
calzaturificio, era inserita nell'ambito di un progetto universitario
(proposto da docenti e ricercatori della facolta' di economia) per lo
studio dell' impatto dell'informatica sulle piccole e medie imprese
(ervamo nel 1999-2000).
Mi ricordo che i titolari del calzaturificio erano molto soddisfatti
perche' dicevano che prima, per far vedere i dati sia ai clienti, sia ai
propri dipendenti dovevano ricorrere alla "gestione dei file di AS400"
(che per la verita' non ho mai ben capito cosa fosse, perche' io in quel
progetto ho lavorato sulla parte che prendeva il "tabellone" inviato da
as400 e lo convertiva in forma "umana" per essere esportato sul web. La
parte che prelevava i dati da AS400 e mi inviava il tabellone la faceva un
altro, tra l'altro fisicamente distante 30-40 di Km da dove ero io,
perche' io e il server Linux eravamo a Pisa, mentre il calzaturificio e il
relativo AS400 erano in un paese ad appunto circa 30-40 Km da Pisa. Quindi
per me
AS400 ha sempre continuato ad essere un mistero, nonostante quel progetto).
Comunque all'epoca eravamo ancora all'interno della New economy e, secondo
i titolari del calzaturificio, un sistema simile allora avrebbe potuto
interessare anche qualche loro cliente in Portogallo.
Io all'epoca avevo poca esperienza e per la verita' ero per la verita'
piu' interessato a divertirmi lavorando che non a fare soldi, altrimenti
avrei potuto provare a muovermi indipendentemente da quello che era il mio
"datore di lavoro" dell'epoca (ovvero un laboratorio universitario che in
qualche modo partecipava al progetto e che non pareva interessato ad
espandere le proprie possibilita' oltre l'ambito dello studio
universitario) e provare a fare qualcosa
Tra l'altro, nel 2006, con una certa mia sorpresa, mi telefono' il tizio
che all'epoca mi spediva il "tabellone" con i dati presi da AS400,
chiedendomi se avevo ancora un backup del software che girava su Linux (io
nel 2001 me ne ero andato dal laboratorio universitario) perche' il server
Linux era stato "formattato" da uno dei responsabili del laboratorio
perche' l'esperimento dello studio degli effetti dell'informatizzazione 
sulle PMI era terminato ma quelli del calzaturificio dicevano che quel
software lo usavano ancora.
Il problema e' che allora venivano finanziati ad esempio progetti
universitari in cui potevi sperimentare cose come questa e quindi il costo
non era sostenuto, se non in minima parte, dall'azienda che beneficiava
del software. 
Quindi potevi prima realizzare qualcosa e poi farlo vedere al potenziale
"committente" che eventualmente, se interessato, poteva chiederti
qualcos'altro.
Oggi se vuoi fare qualcosa del genere devi chiedere all'azienda che te lo
finanzi. E immagino che la risposta sarebbe: "AS400 ha sempre funzionato
bene. Che bisogno c'e' di avere qualcosa di diverso?"
Ciao,
Marco.


 bene. Che bisogno c'e' di avere qualcosa di diverso?"
Che sarebbe una risposta sensata, se per rifare tutto gli chiedi una
cifra cospicua in relazione alla dimensione dell'azienda.
Perfino colossi come Telecom, tante banche, ecc., che possono anche
rischiare somme importanti, si tengono alcuni "antichi" applicativi
Cobol. E penso sia lo stesso anche all'estero.

 wrote:
zac
Presente!
Ho letto tutto.....e paradossalmente (imho) tutti hanno ragione!
Dipende dal tipo di programma.
Programmi pacchettizzati standard....un teamsystem...uno
zucchetti.....tanto per non fare nomi.
Hanno la manutenzione come fonte di business.
Io nel mio piccolo faccio altrettanto....ci sono programmi che vendo
ad un prezzo basso e poi mi "rifaccio" con l'assistenza! Ovvio il
programma deve essere studiato bene e avere poche fonti di problemi.
MA
se il cliente ti chiede una stampa con titolo rosa(mi è
successo)....oppure un nuovo report....o di vedere i clienti ordinati
secodo un suo criterio del caz....per N-euri al mese già
riscossi....non lo fai?
Io che sono anche imprenditore di me stesso sono contento di
farlo....tu mio ipotetico dipendente.....forse meno! Sono le sfighe
della vita!
Ovvio che poi c'è il "programma-malox"
quello che ti porta a dipendere dalla bottiglietta di liquido bianco!
Io avevo una collaborazione con una università per sviluppare un
programma....ogni 15 giorni riunione con il ricercatore che non
variava solo le richieste ma anche la struttura del database in base
alle richieste dei colleghi sparsi per il mondo.
Alla fine ho avuto l'onore di essere citato su internet come
collaboratore del progetto (oltre che essere pagato)....ma è stato un
bagno di sangue durato un anno!
Però una volta o due nella vita si fa!...per quella volta solamente
contano anche le soddisfazioni....mica solo i soldi!
Saluti!
p.s.
Dipende anche dalla zona
Io che sto a Prato dove le aziende che chiuduno giornalmente si
contano con due mani non è il momento di proporre investimenti ai
clienti...ma di stare raccolti e far quadrato sperando "che passi
a'nuttata"!!!(sperando che si scriva così)

vengono totalmente riscritti ?
Intendiamoci, quando dico revisione, ri-scrittura, non sempre
significa portare da emulazione a caratteri a gui, anzi quello e'
accaduto in un numero limitato di casi, per il resto e' difficile
rispondere in termini di successi/insuccessi.
L'approccio usuale e' quello del cliente che vuole aggiungere questa o
quella funzionalità ad un prodotto che gia di base lo soddisfa,
(chesso' spedire le conferme degl'ordini via email o gli avvisi di
consegna via sms), oppure si trova di fronte una nuova necessità
operativa prima non contemplata:  mostrare in tempo reale la
disponibilita' del magazzino (per aggiornare l'e-commerce o per
facilitare la vita agli agenti), razionalizzare l'utilizzo degli
impianti in base agl'ordini.
Esigenze molto diverse, ma che fondamentalmente non richiederebbero
nessuna riscrittura ex-novo. Anche perche' all'imprenditore che ha
spesso 80/100 milioni delle vecchie lire per la gestione della
logistica e del magazzino nel 1995, e' duro far comprendere che nel
2005 dovrebbe riprendere tutto in mano, modificare tutte le procedure
operative ed il workflow (che altrimenti riscrivere da capo non ha
senso), per quale vantaggio pratico? (ed onestamente pure noi a casa
mica stiamo ogni 5/7 anni a cambiare la lavatrice o la macchina del
gas).
Pero' a volte (sinceramente una minoranza di casi) la riscrittura si
pone come necessità concreta o come vantaggio costi/obiettivi tout
court.
Anche l'utilizzo dello strumento dipende dallo scenario: se si
interviene ad esempio con un verticale di una procedura gia esistente
(chesso' ACG, SAP o JDE) e' ovvio che ci siano precondizioni piu' o
meno flessibili di intervento.
Tool di conversione del codice (da RPG/COBOL a JAVA, si chiama Caravel
ed e' prodotto da una societa' madrilena la Trans Tools, fortemente
sponsorizzata da IBM) li ho usati in due occasioni, abbastanza da dire
mai piu'. 
Piu' frequente l'utilizzo di screen scrapers (Webfacing, JWalk et
similia), non mi appasionano, ma si raggiunge il risultato senza
grandi sforzi, ed in genere il cliente e' contento perche' rimane
ancorato ad una logica operativa "familiare" per lui.
 
Riscrittura ex-novo "built from scratch" l'abbiamo affrontata in
alcune occasioni, ma in genere per il cliente è l'extrema ratio a
fronte di avvenimenti epocali (acquisizioni e necessita di integrare
piu' reltà, crescite o ridemensionamenti aziendali, ri-collocazione
sul mercato, cose che va da se non accadono tutti i giorni). Noi come
tecnici la predilegiamo come soluzione, come imprenditori e
(auto)markettari mi sento di essere piu' cauto, non sempre puo' valere
la pena/vantaggio economico, a volte anzi altri strumenti di cui
sopra, magari tecnicamente considerati al livello di "accrocchi"
garantiscono una maggiore soddisfazione del cliente.
Diciamo che in genere l'utente ha avuto cio' che voleva, anche perche'
le fatture ce le hanno pagate tutte e le uniche insolute che abbiamo
non riferiscono a questo genere di attivita', lo sforzo maggiore e'
stato quello di riuscire a trasmettergli la consapevolezza di cio' che
chiedeva e di cio' che avrebbe avuto a fronte di quello che voleva
spendere. Se si riesce in questo e' arduo che il progetto possa
diventare un fallimento, ma la mia realtà di riferimento e' la PMI (+
M che P), ci sono e' vero i c.d. "Padroni del vapore" ma piu' spesso
(soprattuto quando l'azienda esiste da piu' di una decina d'anni) c'e'
gente si attenta a come spende i soldi ma cosciente che li deve
spendere in una certa maniera.


ehm mi spiace, io fortunatamente seguo un progetto ex novo e uno stra
vecchio a cui faccio la manutenzione straordinaria e non posso perderci
più di due giorni la settimana.
Il rovescio della medaglia è che se ci sono modifiche assurde quei due
giorni diventano di 11-12 ore...
ma è un buon compromesso stare 5 giorni la settimana su vecchi progetti
non miei mi farebbe sclerare

 8)Ho le mie librerie in C# ampiamente riutilizzabili.
7-8) questi punti non sono controbattibili, i gusti e le preferenze
personali sono sante!!!!

 non miei mi farebbe sclerare
ma anche a me mi alternano per fortuna!! Maledetto me che conosco 
abbastanza bene delphi!! :-( c'e' uno che conosce solo .net e fa solo 
quello!
cioe' alla fine chi conosce piu' roba e' penalizzato!


ehm beh...
però non è la fine del mondo mantenere un'applicazione delphi, a me
delphi piaceva, pensa addirittura che sto usando nel tempo libero
lazarus freepascal (che ricorda delphi 5-6) per sviluppare
un'applicazione di gestione cantieri per mio padre e sta pure venendo su
bene...

 garantiscono una maggiore soddisfazione del cliente.
purtroppo ti devo quotare penso anch'io piu' o meno la stessa cosa! :-D
ciao
ps
se i sistemi clouds come io spero cambieranno un bel po' di cose...

 bene...
ma infatti non e' colpa di delphi e' colpa del codice :-(
cioe' c'e' un componente che disegna una griglia temporale e 
praticamente sto cacchio di componente e' abbastanza statico tipo ha 
solo 2 header etc e nel codice non si capisce una sega!!
e' 2 giorni che sto andando per tentativi :-D
e' tutto cosi' ogni volta che tocco qualcosa si smongola da altre parti 
buona parte del codice e' cosi', senza una riga di commento!! :-(
Canvas.Brush.Color := elementsLink.LinkColor;
Canvas.Rectangle(x - 4, y - 3, x + 3, y + 4);
Canvas.Pixels[x - 1, y] := clWhite;
Canvas.Pixels[x, y - 1] := clWhite;
Canvas.Pixels[x, y + 1] := clWhite;
Canvas.Pixels[x - 2, y + 1] := clWhite;
naturalmente chi la fatto si appoggia su degli array(:-( ) il cui indice 
ogni tanto parte da -1 ogni tanto da 1 ed e' tutto un out of bounds!! LOL
ps
devo aggiungere un header e alcuni elementi ci mettero' una settimana... 
ma tanto mi pagano lo stesso amen! :-D

 ma tanto mi pagano lo stesso amen! :-D
ah ah capisco... magari è un componente costruito per tentativi visivi,
ne ho rivisti pure io... con array che alle volte partivano da 0, altre
da 1, altre da 5 (mai capito il motivo)
soluzione?
mi sono riscritto il componente per reverse del comportamento perchè da
codice zack non si capiva davvero una ceppa...

 codice zack non si capiva davvero una ceppa...
il mio boss non vuole! eppoi e' abbastanza grosso gestisce anche drag 
&drop di elementi ci vorrebbe almeno almeno un mesetto di tempo! :-(
gli dei mi sono avversi!! :-( :-(

 
devi sacrificare un consulente in 
co.co.co.pro
 vergine all'abate
Vermetin perché preghi per la salvezza della tua stabilità mentale!

 pare una cazzata forzarci una miriade di modifiche alla fine ci si mette
Allora, imho i software "core", quelli che servono a far funzionare
l'azienda dovrebbero avere una vita media dai 5 ai 10 anni, non di
più.
Semplicemente perchè necessità funzionali e tecnologia cambiano così
rapidamente che per mantenerti competitivo ti serve un software nuovo.
Il che non vuol dire rifare tutto. Se lo progetti bene il sistema i
servizi base ed il DB possono rimanere gli stessi per decine di anni,
ma interfaccia e tecnologia vanno aggiornati.
Ovvio che se ragioni così non puoi spendere tantissimo nella scrittura
del software, dovresti prediligere architetture semplici se non banali
e scorciatoie su soluzioni che oggi sembrano "eterne" ma che sono
complesse e costose e che fra 10 anni faranno solo ridere.
Detto questo c'è un grosso grosso problema nel buttare tutto e
rifare : il rischio. Io azienda, per  decidere di rifarlo devo  :
- Fidarmi di chi  mi propone di rifarlo (ed essermi scordato del
tempo, soldi e sangue spesi nella prima stesura )
- Vedere un vantaggio che un nuovo software avrebbe sull'assumere
altri 2 a TD a 700 euro al mese per sopperire alle manzanze del
software
IMHO questi sono i due grandi problemi della nostra professione :  le
fregature tirate negli anni con l'enorme quantità di progetti finiti
in caciara e il basso costo delle risorse umane.
Meno paghi le persone e meno conveniente è il software, leggevo di una
grande azienda Cinese che gestisce le spedizioni a mano..
completamente : riceve le email di ordine e li scrive su carta. Ci
sono molte persone che ci lavorano, ma costano talmente poco e sono
talmente brave a gestire situazioni non standard che convengono
rispetto ad un software.
E così' da noi, in certe realtà conviene quasi prendere 2 persone a
ridigitare i dati integrandoli da due diversi sistemi che scrivere un
software che lo faccia.

 Marco.
Andrea 

 6) va bé io lavoro più volentieri su server linux.
Sono gusti e opportunità trovate, se avessi dovuto fare lo stesso avrei 
probabilmente detto lo stesso.
