Newsgroup: it.lavoro.informatica
Titolo: Il programmatore odierno


-- 
Living in Barbaropoli
http://www.barbaropoli.com


Un marea di cazzate e pericolose (ripeto, pericolose) ovvietà. Non
meno filonazista del famoso proprietario del negozio di Roma...

meno filonazista del famoso proprietario del negozio di Roma...
Quindi uno che ti dice io programmo, non mi interessa sapere di
networking e di come l'OS gestisce i socket non sta dicendo una
cazzata?



Guarda, potrebbe anche avere ragione sul fatto che oggi i programmatori si
comportano in un certo modo, ma *sicuramente*, in tipico italian-style
(ovvero quello che a lui non piace, ma non si rende conto di farne parte
al 100%), confonde assolutamente la causa con l'effetto. 
Ovvero:
 il fatto che i programmatori oggi ti dicano:
Capacita'? Non my problem. Peculiarita' del sistema operativo? Not my
problem. Protocolli di rete? Not my problem. 
secondo lui da dove deriva ? Dal fatto che il programmatore preferisce non
fare il tecnico ? Una mi****a!
La risposta e' molto semplice: il manager italiano della grande azienda di
telecomunicazioni *impone* al programmatore di rispondere cosi' ogni volta
che gli viene chiesto qualcosa. 
E se per caso il programmatore prova ad approfondire (ad esempio per
capire come funziona lo scheduler di Solaris che magari e' diverso da
quello di Linux), il grande manager italiano della grande azienda di
telecomunicazioni si incazza perche' "il programmatore sta perdendo tempo"
e magari viene anche cacciato, perche' invece di perdere tempo con cazzate
tipo "come funziona lo scheduler" poteva fare cose molto piu' utili, tipo
"abbellire il manuale utente". 
Ho sentito non piu' di due settimane fa il project manager chiedere
esplicitamente a dei colleghi di fare "prima" gli aggiornamenti al manuale
utente e sistemare le interfacce grafiche del loro sistema per gli utenti
che le usano e solo *poi* sistemare i malfunzionamenti della "business
logic", perche' "e' piu' importante che gli utentia abbiano il manuale e
le interfacce corrette in tempi rapidi".
E siccome chi paga vuole merda, merda avra'. E siccome chi paga vuole
programmatori che *non perdano tempo* a capire come funziona lo scheduler,
ovvero vuole programmatori incompetenti, programmatori incompetenti avra'. 
E, da parte sua, il programmatore che viene cazziato perche' sta tentando
di capire come funziona lo scheduler mentre viene pagato quando fa un bel
manuale utente ovviamente se ne strafottera' in futuro degli scheduler e
passera' sempre piu' tempo a disegnare belle figure per fare dei bei
manuali utente. Cosi' perdera' competenze tecniche e diventera' un artista
del livello del Caravaggio nel disegnare figure per i manuali (forse e'
per questo che si tenta di limitare l'accesso alle universita' da parte di
chi ha fatto scuole tecniche per favorire chi ha fatto il liceo classico.
Come dargli torto!)
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 cazzata?
O scritto cazzate E pericolose ovvietà. Il titolare del blog in
questione, nessuno nega sia un ottimo tecnico, ma ha tanto tantissimoo
da imparare in quanto a relazioni umane e dinamiche commerciali.
Un programmatore che dice così vuol dire due cose:
1) Ha un PM che non sa fare il PM
2) Magari lavora da solo o è un'outsider del cavolo.
Se scrivessi dei miei 11 anni passati a lavorare dopo la laurea
(ometto per carità di patria il periodo 94 / 97) avrei ben altre cose
da scrivere che un inutile ricettario di ovvietà (oltre a dire che in
Italia nelle università non si investe un cazzo, ma non dice per colpa
di chi)
(chi ti scrive ha lavorato in tutte le altre telco Italiane che non
sono Vodafone + un 3 anni all'estero)
Tranne 2 cazzate in croce su FB un blog ce l'avevo e l'ho tolto:
magari non so scrivere, magari mi scoccio, magari passo più tempo a
lavorare...
Fa ridere che invece sia  proprio lui che fa "black magic" proprio
come quelli di cui scrive che vanno a Londra...
Con questo non criminalizzo chiunque scrive blog, per esempio quelle
volte che sono andato sul tuo, almeno non ho perso tempo a leggere
cose risapute
Ciao


 Living in Barbaropolihttp://
www.barbaropoli.com

Ciao
Tutto quello che leggi su un blog va preso con le pinze.
Quando dice che ha a che fare com programmatori che non si preoccupano
di cercare librerie che performino/scalino o a cui non gliene frega
niente sapere un minimo di teoria di reti o delle eventuali
limitazioni dell'OS in cui l;applicativo girera', mi pare stia dicendo
cose sensate.
Il pezzo del programmatore fallito che si ricicla a londra, per dire,
non lo prendo in considerazione, come non penso che tutti vogliano
diventare PM dopo 3 anni di sviluppo.
Saluti.


 cazzata?
Sta dicendo una cazzata per il semplice fatto che notare che il
programmatore ti dice "io programmo, non mi interessa sapere di networking
e di come l'OS gestisce i socket " senza valutare i motivi per cui il
programmatore ti dice cio' significa essere al pari di quel programmatore
che crede che sia sufficiente di conoscere java. Per valutare una persona
piu' che un programmatore dovresti anche andare a vedere perche' ti dice
certe cose (proprio allo stesso modo in cui anche chi programma in java
dovrebbe conoscere anche i dettagli a basso livello del sistema operativo).
Cioe' il programmatore ti dice cosi', perche' il manager italiano della
grande azienda di Telecomunicazioni gli insegna che *deve* rispondere
cosi'. E gli insegna anche che, piuttosto che "perdere tempo" e "far
perdere soldi all'azienda" con "cose inutili" come capire le differenze
tra il funzionamento dello scheduler di Solaris e quello di Linux e' molto
meglio fare dun bel manuale utente con delle belle figure. Al massimo due
settimane fa e' passato di qui un Project Manager (anzi una Project
Manager) che diceva a dei colleghi (abbastanza oberati da attivita' di bug
fixing della business logic di una loro applicazione) che era piu'
importante avere un manuale utente fatto bene in tempi rapidi e delle
interfacce grafiche con un bel layout e delle label sistemate bene per cui
era meglio sospendere le attivita' sulla business logic e concentrarsi sul
manuale utente e sulle interfacce grafiche.
Quindi, se il manager italiano vuole merda, merda avra'. Poi c'e' poco da
stupirsi che uno ti fornisca merda. Ti fornisce quello che chi paga vuole
che lui fornisca.
Ed e' strano che uno che fa tutti quei discorsi sui manager londinesi (che
non conosco) non arrivi a capire delle ovvieta' sui manager italiani.
E tra l'altro, poiche' i manager amano circondarsi di quelli che la
pensano come loro, capitera' che se un programmatore avesse voglia di
mettersi a capire come funzionano i vari scheduler, questo avrebbe molte
piu' probabilta' di essere allontanato che non uno che disegna delle belle
figure per i manuali utente. Per cui alla fine tutti i "programmatori
esperti" saranno sempre piu' "artisti" e meno "tecnici". Cosi' si avranno
(o forse si hanno gia') dei tecnici che perderanno competenze tecniche a
favore di competenze artistiche, attivita' in cui potranno raggiungere i
livelli del Caravaggio. Forse e ' per questo che si tenta di
disincentivare l'accesso alle universita' da parte di chi ha fatto scuole
tecniche a favore di chi ha fatto il liceo classico. E visto come vanno le
cose non si puo' nemmeno dargli torto.


 cose sensate.
Quello che non e' sensato e' non chiedersi perche' cio' accade (vedi i
miei altri post)
Ciao,
Marco.


miei altri post)
E quando il manager italiano non c'entra?


 meno filonazista del famoso proprietario del negozio di Roma...
A me sembra sano buon senso, magari espresso in maniera "non politically 
correct". Ma fondamentalmente ha ragione su tutti i fronti.
 


Spettacolare! :-D
Ogni tanto sembra contraddirsi e su qualcosa non sono d'accordo, 
tuttavia  in linea di massima ha ragione su molte cose.
La parte sull'italiano a londra mi ha fatto crepare dal ridere:
"Londra e' un posto, cioe', privo di anticorpi contro i cialtroni italiani."
"Duecento anni di economia basata su commercio e servizi hanno creato un 
mondo di manager che non saprebbero piantare un chiodo nel muro, e che 
credono onestamente che i muri escano di fabbrica con il chiodo gia' 
inserito. Capite che se a questa persona fate vedere che piantate un 
chiodo nel muro, siete degli dei."
Black magic.
ROTFL! :-D
-- 
http://www.evilripper.net
http://www.flickr.com/photos/evilripper/


Non mi ricordo chi (forse balmer, boh), ma in MS c'era uno che insisteva con 
il concetto del tipo: ci sono quelli che han bisogno di sapere troppi 
dettagli sui vari layer di interfacciamento per fare applicazioni, non 
preoccupatevi, ci penserà la selezione naturale.
Una roba simile insomma, solo che non ho capito se con la selezione naturale 
si riferiva al fatto che quelli che vogliono comportarsi in quel modo 
saranno i vincenti o i perdenti... :-)


WTF ?
" Page Not Found
We cannot locate the page you're looking for. Please check the address and 
make sure all letters are lowercased with no spaces. "
è uno scherzo? o è così sovversivo da essere stato bloccato? :)
Gabriele

 correct". Ma fondamentalmente ha ragione su tutti i fronti.
Se ti pare che abbia "ragione su tutti i fronti" fai lo stesso errore del
proogrammatore che non approfondisce lo scheduler di solaris. Ovvero non
approfondisci tutto cio' che c'e' da sapere per fare il programmatore(vedi
gli altri miei post).
Ciao,
Marco


 saranno i vincenti o i perdenti... :-)
Ad oggi la "selezione naturale" li ha scelti sicuramente come perdenti.
Ciao,
Marco.


 meno filonazista del famoso proprietario del negozio di Roma...
Mi spieghi il significato di filonazista?
Mi apre che usi questo aggettivo in maniera """aleatoria""". :-)
Ciao,
Giulio
-- 


NSFW.
Comunque pezzo interessante.
Ciao e grazie del link,
Giulio
-- 

 diventare PM dopo 3 anni di sviluppo.
ne ho conosciuti di certo non � mai bene generalizzare...
il motivo principale che adducevano e' quello che non vogliono stare al 
pc troppe ore e che sviluppare e' un lavoro noioso!!
ps
erano tutte CAXXATE non gli piaceva e soffrivano...ma non ammetteranno 
mai di aver buttato nel cesso 7 anni della loro vita all'uni per fare 
questo mestiere e invece di cambiare rimangono nella speranza che le 
cose migliorino quando diventeranno pm!
naturalmente molti di questi oltre che soffrire e schifare piantavano 
dei mostri nel codice!

On 16 Dic, 08:36, Freddy Krueger <inva...@invalid.invalid> wrote:

beh che ci sia un "imbesuimento" generale dei programmatori dovuto al
fatto di essere sempre piu' isolati dall' hardware e' vero ma e' una
questione nota e dicussa da anni. E il fatto che un programmatore
aspiri a trasformarsi in PM prima possibile , e che questo porti alla
mancanza di programmatori bravi ed esperti e' pure vero, ma
bisognerebbe capirne la causa, e la causa e' che almeno in Italia non
esiste la figura professionale del programmatore senior, nel senso che
le aziende italiana concepiscono il programmatore come un tecnico che
viene pagato quattro soldi, e se vuoi avere uno stipendio che si
avvicini almeno alla decenza devi fare altre cose, come ad esempio il
PM.


I programmatori su cui impreca sono solo lo specchio delle tendenze
correnti.
Non c'è dubbio che quanti più strati di oggetti, patterns, framework,
macchine virtuali inserisci tra il problema e la soluzione software,
tanto meno il programmatore si preoccuperà di quello che
effettivamente avviene al livello più basso (s.o., ma potrebbe essere
pure il processore)..
Magari anche perchè diventa sempre più umanamente difficile
districarsi in tale folla di metodi e tecnologie. Ora per fare una
pagina video ci vuole perfino il "designer".... :-))


Infatti io da grande voglio fare il programmatore astronauta... :-)

 PM.
Mah, questo non è del tutto vero. Per esempio, ed a proposito di
batch, se il programmatore "senior" un bel giorno fa vedere che la tal
applicazione che normalmente dura 10 ore può essere ottimizzata ad 1
ora sul medesimo hardware, con conseguenti risparmio di costi,
semplificazione di procedure, più tempo per risolvere eventuali
problemi "mission critical",  ecc., bè allora ha una bella carta per
farsi apprezzare dai managers. Poi se non la gioca bene, affari suoi.
Nessuno regala niente.


non so dove lavori tu, ma nei posti che ho visto io (e ne ho visti
parecchi lavorando come consulente) la bravura e l'esperienza del
programmatore o non vengono valutate del tutto, o vengono valutate nel
senso di "promuoverlo a PM" o viene valutata nel senso di considerarlo
nerd risolvi problemi che viene ricompensato a suon di pacche sulle
spalle...
Quante figure hai visto di programmatore altamente skillato e
specializzato che lavorasse effettivamente come programmatore e non
venisse pagato con le solite noccioline?

 Infatti io da grande voglio fare il programmatore astronauta... :-)
Se trovo una pecca in quell'articolo, che in molte parti condivido, e'
il fatto che si pensa a 'programmatore' e non si pensa che produrre
software implica un processo abbastanza complesso. Anzi, mi verrebbe da
chiedere al tale: cos'e' oggi un programmatore? Perche' questa si era
una definizione anni '70, ma oggi che significa? il code monkey che
riceve una specifica dettagliata e si occupa della sola
implementazione? il progettista? l'analista funzionale?
-- 
Ciao!
Luca

 gli altri miei post).
Si,  va bene, occore conoscere l'ecosistema, la flora e la fauna che popola 
il proprio microcosmo.
 

 wrote in message 
news:iecv81$h7e$1...@tdi.cu.mi.it...

Si dice "scienziato dei missili".
 


Non so, credo che a questa domanda possa rispondere solo un over 60 che 
abbia passato la vita a far sw.
Io non ne conosco...

 farsi apprezzare dai managers. Poi se non la gioca bene, affari suoi.
Guarda, ho un caso che dice come, in Italia, questo non succeda (non
voglio dire che questo accada all'estero, e' che la mia esperienza
professionale qui mi limita.
Un paio di mesi fa, DRAMMA, DELITTO, TEMPESTA, LE CAVALLETTE, una parte
di analisi dati per un'applicazione che avevo scritto andava
pianissimo. Un po' perche' si testava su una quantita' di dati un
ordine di grandezza superiore al previsto, un po' perche' in effetti
c'erano oggettivi problemi di approccio.
Ho sputato sangue per ridurre drasticamente i tempi di esecuzione (e
sono arrivato a soli 35 minuti); la cosa drammatica e' che DA ME, sul
mio PC di 3 anni con un SQL Server Express, ci mette 35 minuti, in
produzione (cluster megagalattico con risorse a sfare) ce ne mette 50!
In ogni caso, era ovviamente colpa del software, per cui nessuno che
mia abbia detto manco un grazie.
-- 
Ciao!
Luca

 AleTV wrote:


La prima che hai detto. La seconda spesso non esiste, a meno di aziende
molto grandi e anche li' non sempre esiste (in genere quella mansione e'
svolta un po' a meta tra la prima e la terza figura). La terza che hai
detto nelle aziende grandi e' sempre distinta dalla prima, anche se,
talvolta, anche questa terza figura non c'e'.
In ogni caso qualsiasi cosa faccia il programmatore, quando anche dovesse
occuparsi della seconda e della terza mansione che hai detto, se sul suo
contratto c'e' scritto "programmatore", la considerazione che tale
programmatore riceve nel momento in cui deve essere pagato e'esattamente
quella della prima che hai detto.


 implementazione?
questo del code monkey e' della "sola implementazione" e' un mito
creato probabilmente da chi la "sola implementazione" non la sa o non
la vuole fare..  E' chiaro che "la sola implementazione" non e' tutto,
anche se con "la sola implementazione" qualcosa di utile alla fine
viene fuori, mentre con "la sola analisi" ti ci puoi pulire il
deretano ( se l' hai fatta su fogli soffici..). Quello che e' in
genere molto meno chiaro e' che "la sola implementazione" non e'
affatto un processo banale che discende automaticamente dalle
specifiche dell' analisi. La "sola implementazione" si puo' fare male,
malino, cosi' cosi', benino , bene o straordinariamente bene a seconda
dell' abilita' e dell'esperienza del programmatore. E questo sia dal
punto di vista dell' efficienza del codice che della sua chiarezza ed
estendibilita'..Finche' noi informatici in primis non capiamo che
creare software non e' la stessa cosa che tirar su una palazzina o
montare un' automobile non riusciremo mai ad avere una considerazione
e un trattamento (economico e non) adeguate.

 venisse pagato con le solite noccioline?
Io :-))
A parte le (mezze ;-) battute, ne ho visti diversi a cui sono stati
dati aumenti e ruoli di maggiore responsabilità, non necessariamente
come  PM. Cosa che non mi sembra un degrado, se uno è bravo a
risolvere problemi tecnici è giusto che vada a dirigere gruppi di
altri tecnici meno bravi o esperti.
Sottolineo: risolvere problemi.

 deretano ( se l' hai fatta su fogli soffici..).
Curiosità: supponiamo di dover sviluppare una rubrica telefonica, con tanto 
di GUI etc...
Dove inizia e finisce la fase di analisi? 

 Dove inizia e finisce la fase di analisi?
Aggiungo: l'analisi comprende anche l'implementazione degli algoritmi magari 
solo a livello di pseudo linguaggio, oppure si ferma alla chiacchiere?
Se devo sviluppare un motore di gioco per gli scacchi, l'algoritmo relativo 
all'albero delle mosse lo modella l'analista o questi si limita a dire 
"bisogna implementare una struttura dati per gestire le possibili mosse"?
Mi chiedevo questo, perché se chi analizza non ha a che fare con algoritmi e 
codice, allora perché si interessa di programmazione?
Il bello della programmazione è studiare un problema, trovarne la soluzione 
ed implementare il codice frutto del tuo ragionamento. 

 deretano ( se l' hai fatta su fogli soffici..).
Su questo concordo. Il fine della IT è fornire software funzionante.
Non è nè riempire carta con schemini, ma -attenzione!- neppure seguire
alla lettera i manuali del "bravo programmatore".
Ergo, anche con le belle progettazioni secondo i canoni dei framework,
tiers, ecc. spesso ti ci puoi pulire ciò che sta davanti al deretano,
perchè nel mondo reale sono zavorre inaccettabili :-))

 ha scritto:



Procedimento da grande azienda:
Il PM contatta il cliente per la fase di presales. Gli chiede  un
documento dei requisiti. Una volta ottenuto il documento dei requisiti
(dove piu' o meno ci sara' scritto: "mi serve una rubrica telefonica"), il
PM o chi per lui/lei (il "chi per lui" potrei essere io ad esempio)
provvede alla redazione di un Allegato Tecnico da far firmare al cliente e
al dirigente della grande aziende, insieme all'offerta economica (anche
questa preparata dal PM o da chi per lui. In questo caso il "chi per lui"
non sono io).
Nell'Allegato Tecnico in genere c'e' scritto qualcosa del tipo "Noi,
<megaazienda di qua e di la> proponiamo la seguente soluzione tecnica per
la richiesta prodotta nel <documento dei requisiti>" e si butta li' uno
schizzo dell'interfaccia grafica per la rubrica, con una vaga descrizione
di come si usa e, se chi scrive l'AT sono io, magari anche dei campi
principali del db (se si usa un db). In teoria poi nell' Allegato Tecnico
ci va scritto anche quando il progetto sara' consegnato al cliente e
andrebbe motivato perche' si e' scelto proprio "quella soluzione" e non
"un'altra soluzione". E la soluzione scelta andrebbe anche scomposta in
"macroattivita'" (tipo "sviluppo dell' interfaccia", "creazione del db",
"sviluppo delle funzionalita' di gestione utenti", "sviluppo delle
funzionalita' di ricerca", ecc.) in modo tale che il PM poi potra' dire:
- lo sviluppo dell'interfaccia grafica "quota" X giorni/uomo
- lo sviluppo delle funzionalita' di gestione utente "quota" Y giorni/uomo
ecc.
Con L'offerta Economica e l'Allegato Tecnico il PM puo' andare dal cliente
e dirgli: "il progetto costa Tot1 e te lo possiamo consegnare in Tot2
giorni/uomo dalla data dell'ordine". Quindi quando il cliente emette
formale ordine, si potra' iniziare a implementare.
In genere mentre si aspetta l'ordine si passa al documento di specifiche
tecnico funzionali, fatto dall'analista funzionale (di solito io) o chi
per lui dove si entra un po' di piu' (ma non troppo) nei dettagli tecnici
del sistema, compresa l'eventuale infrastruttura (ad esempio se la rubrica
la vuoi gestire "via web" potrebbero essere contenuti in questo documento
i dettagli del server, l'eventuale dimensionamento dello
stesso,l'eventuale HW e/o SW da acquistare per realizzare il progetto,
ecc.)
Poi si passa all'implementazione e, teoricamente, piu' o meno in
contemporanea ai documenti di specifiche tecniche dettagliate (contenenti
in teoria i dettagli sulle classi, i campi del db, ecc.), l'eventuale
manuale utente e le eventuali specifiche di navigabilita' e usabilita' nel
caso di progetti accessibili "via web" dagli utenti. In questa fase o
nelle precedenti può anche essere preparato un Kit Di Test dai tecnici o
chi per loro (spesso io), anche se, teoricamente, ci dovrebbe essere la
funzione di testing aziendale che provvede a prepare i kit di test ed
eventualmente automatizzare i test stessi. Pero' visto che spesso la
funzione "testing" "costa un botto", il PM, per progetti abbastanza
semplici che non richiedono test di carico spinti o cose simili, 
preferisce che
i test vengano fatti "a mano" (e quindi spesso li faccio io).
Terminata l'implementazione e pronto il kit di test si passa alla fase di
test e stesura dei report relativi (spesso fatti da me, almeno quando non
servono strumenti per l'automazione dei test stessi).
In genere i kit di test e i report prodotti da me sono facilmente
riconoscibili in quanto portano nell'intestazione la dicitura:
"Program testing can be used to show the presence of bugs, but never to
show their absence!" (Dijkstra) 
o qualcosa di simile. La metto nella speranza che qualcuno si renda conto
dell'immane cazzata che stanno facendo, pensando che se il test viene
superato allora il software e' corretto, ma non mi pare che se ne rendano
conto, anzi...
I test possono dover essere ripetuti n volte in vari ambienti (potrebbe
esserci l'ambiente di test, quello di collaudo, quello di produzione e, a
volte, anche quello di certificazione distinto dai precedenti). A volte
gli ambienti ci sono tutti, a volte ce ne e' uno solo, altre volte ce ne
sono alcuni e altri no, ecc.
Se i test falliscono (cioe' se non rilevano alcun malfunzionamento) allora
il PM provvedera' a far firmare al cliente i vari verbali (collaudo,
certificazione, ecc.) e il progetto potra' andare in Erogazione.
La funzione "Erogazione" e' un'altra funzione aziendale che costa un botto
di soldi. 
La fase di analisi cominicia piu' o meno con l'allegato tecnico (a volte
anche dalla raccolta dei requisiti) fino alle specifiche tecnico
funzionali (a volte anche specifiche tecniche di dettaglio). Poi
ovviamente, se ad esempio in fase di test venissero fuori dei "buchi"
nelle analisi fatte in precedenza c'e' da rianalizzare il sistema, ecc.
Quindi, ai fini della produzione di una rubrica telefonica, per una grande
azienda c'e' da considerare i seguenti costi:
- il dirigente che deve firmare i contratti
- il PM che dovrebbe seguire piu' o meno tutte le fasi del progetto
- l'analista funzionale che deve seguire le fasi diciamo "intermedie" del
progetto (da quando ci sono i requisiti fino allo sviluppo)
- i costi degli sviluppatori (unica funzione aziendale che in genere e'
esternalizzata al 100%).
Qui bisogna aggiungere i costi del bodyrentallaro che fanno piu' che
raddoppiare i costi di questa fase.
- i costi della funzione aziendale di Testing (che ha i suoi dirigenti e i
suoi tecnici [che in genere sono DBA e gente che lavora su robe di Mercury
che servono ad automatizzare i test]. In teoria anche la funzione
"analisi" dovrebbe avere i suoi dirigenti e i suoi analisti )
- i costi della funzione aziendale di Erogazione (ovvero quelli che
prendono il software e lo installano sulle macchine aziendali di
produzione, eventualmente acquistano le macchine aziendali per il
progetto, se serve acquistarne di nuove). Questi costi comprendono anche i
costi di manutenzione in quanto se c'e' qualche problema ci deve essere
qualcuno che puo' esaminare i log, eventualmente riavviare servizi, ecc.
In altre parole quelli che lavorano in questa funzione (in genere
sistemisti e DBA) saranno gli unici che potranno in qualche modo
sopravvivere all'imminente morte dell'informatica tutta. Ma anche loro
saranno sempre di meno.
Fine apporoccio grande azienda.
Approccio da singolo programmatore
-----------------------------------
Mi serve una rubrica telefonica,
comincio a scrivere le varie funzioni (inserisci, modifica, cancella,
ricerca). Se va bene prima delle funzioni faccio un disegno a mano su
carta di quella che vorrei fosse l'interfaccia grafica. Se va proprio alla
grande preparo anche lo schema del DB prima di scrivere le funzioni.
Una volta scritte le funzioni le provo.
Se il tutto funge ci metto l'interfaccia, la provo... 
et voila'.  Les jeux sont faits, Rien ne va plus (se si scrive cosi')
e si passa al prossimo software.
Ciao,
Marco


 ed implementare il codice frutto del tuo ragionamento.
Il problema e' che al PM e al dirigente che firmano i contratti non
interessa fare qualcosa che "e' bello" ma interessa fare qualcosa che
riempia le loro tasche. E spendere meno tempo possibile nella
realizzazione di un algoritmo che e' pagato bene dal cliente riempie le
loro tasche come nessuna altra cosa al mondo. E tutti gli altri devono
fare quello che decidono il PM e il dirigente


 Sottolineo: risolvere problemi.
Mi sa che tu di PM ne conosci pochini...


 ed implementare il codice frutto del tuo ragionamento.
ci sono varie "interpretazioni" della "fase di analisi", specialmente
visto che raramente si segue un processo di sviluppo formalizzato. In
teoria l' analisi vera e propria comincia appena tu mi enunci il
problema da risolvere: "voglio un agenda" o "voglio un programma che
giochi a scacchi", per definire meglio il problema e il dominio in cui
deve essere risolto..Seguono un' analisi della fattibilita' della
soluzione, con relativi tempi, costi e rischi, e infine la specifica
dei processi di "business" o di "gioco" che il software dovra'
implementare (tipicamente stilata insieme ad un esperto del dominio,
cioe' di uno che presso il cliente si occupa degli stessi problemi che
il software dovra' trattare) e la definizione in dettaglio dei
requisiti richiesti al software sia dal punto di vista funzionale che
da quello della performance. La fase di analisi termina quando
comincia quella di design, anche se a volte si intende come "analisi"
anche il design. Quello che accade di fatto e' che la maggior parte
delle societa' non segue un processo standard ma ha il suo piccolo
processo ( e quindi il suo piccolo modo di "fare analisi") fatto in
casa, se ne ha uno..
La risposta alla domanda: perche' molti programmatori finiscono a fare
analisi ha varie risposte:
1) in italia un programmatore e' considerato piu' o meno al livello di
un tecnico che ti aggiusta la fotocopiatrice.
ergo e' estremamente difficile trovare habitat dove sia possibile dove
non ci sia un tetto massimo estremamente basso al tipo di
soddisfazioni economiche o no che un programmatore esperto puo' avere.
Se vuoi fare carriera devi lasciare la programmazione.
2) esiste un gran numero di programmatori che fa questo mestiere non
perche' ami la programmazione ma perche' e' un mestiere dove una
persona realtivamente sveglia puo' praticare anche senza avere un'
educazione formale e mirata ( anzi vista la qualita' dell' universita'
italiana e la velocita' con cui si muove l' informatica a volte e' un
vantaggio non averla..) Quindi molti programmatori non fanno questo
mestiere perche' gli piace ma semplicemente perche' non hanno trovato
altro nei settori che gli interessano veramente. E siccome programmare
non e' un lavoro "neutro" come fare l' impiegato, nel senso che
richiede concentrazione, tantissima energia e un' attenzione ai limiti
del maniacale e' del tutto naturale che chi non ha vera passione per
questa attivita' tenti di passare ad altro,  a qualcosa di un po' piu'
"neutro" come l analisi, appena possibile
3) in italia non arriviamo a vedere questo fenomeno perche' i
programmatori cambiano mestiere appena possono, ma temo che esista
anche una ragione "fisiologica" per cui con l' invecchiamento si
diventa piu' "lenti", meno capaci di concentrazione a lungo termine,
di attivita' continua e "feroce"..e la programmazione e' un' attivita'
che richiede un' energia e una freschezza proprio "fisica".... per cui
naturalmente ci si lascia trascinare verso attivita' piu'
"coordinative" e "decisionali" che verso la vera e propria
"creazione". Questo e' vero per qualsiasi "scienza" o "arte"  che
richieda un vero sforzo intellettuale, ed e' del tutto naturale,
ragionevole ed accettabile. I veri problemi sono i primi due che ho
elencato..

 Saluti.


 --

 > ed implementare il codice frutto del tuo ragionamento.
...... cut ....
Piu' passano gli anni e piu' si rafforza una mia convinzione :
L'Analista non esiste.
L'Analista e' un passacarte telefonista segretario tuttologo.
Ci sono solo 2 figure che contano : 
1)Il committente
2)IL developer,l'architect o chi vuoi che e' quello che ingegnerizza la
soluzione
Il committente e' l'unico che conosce davvero quello che vuole.
In un modo o nell'altro il flusso e' deve andare cosi':
committente -> developer( team )
Alla fine il developer arriva allo stesso grado di conoscenza della
soluzione del committente ovviamente, altrimenti il SW non
corrisponderebbe alla soluzione voluta.
Ciao Nicola


 committente -> developer( team )
Io concordo. Il PM e il dirigente concordano meno.
Pero' se ti presenti e fai abrogare tutto cio' che sta in mezzo tra
committente e developer potrai avere il mio voto.
Pero' allo stato attuale chi ha approvato la legge Biagi mi sa che non
vuole....
C'e' bisogno di una serie di intermediari perche' "piu' affidabili" del
devoloper.
Ciao,
Marco


 Approccio da singolo programmatore
Di gran lunga superiore ;-) 


Letto x curiosita' visto l'interesse che genera qui. 
Vi consiglio di spendere meglio il vostro tempo piuttosto che leggere la 
eBile di un geek incartapecorito che non conosce i principi base del "buon 
programmtore". open() e close() ?? prima fallo funzionare e poi facciamo i 
performace test. Roba da ridere. 
E voi gli andate anche dietro. Si che qui il livello e' basso ma non 
credevo cosi tanto.
Saluti,
Alex
-- 
Alex75

 committente e developer potrai avere il mio voto.
peccato che far abrogare la legge ha bisogno del tuo voto,
ma per avere il tuo voto deve far abrogare la legge,
ma per fare abrogare la legge ha bisogno del tuo voto,
ma per avere il tuo voto deve far abrogare la legge,
etc etc etc :)

 Di gran lunga superiore ;-)
Questo era piu' o meno l'approccio usato in un laboratorio universitario
in cui ho lavorato circa 3 anni dopo la laurea. A meno che non si
trattasse di un progetto europeo, per il quale la comuniata' europea
richiedeva comunque approcci simili a quelli della grande azienda. Pero'
la durata dei progetti in questi casi era di 2-3 anni (in teoria. Io ho
lavorato ad un progetto che era gia' iniziato quando ho iniziato io e mi
hanno detto che in realta' la durata totale di quel progetto alla fine e'
risultata essere pari a 6 anni); per cui l'overhed delle scartoffie sulla
programmazione, sulla totalita' del progetto incideva sicuramente meno di
quanto incida nelle grandi aziende.


 
Osid, ancora sei giovane. Lascia stare quello che scrive il tipo in 
questione. Non ha la minima idea del tradeoff tra performace e 
scalabilita'. Non credo sappia che differenza c'e' tra vertical e 
horizontal scalability. In sintesi: non gli farei toccare neanche l'XBOX 
di mio figlio. 
In questo lavoro piu' cresci e piu' devi stare attento alla "big picture" 
dettagliando solo la parte "core". I dettagli degli open() e close() si 
lasciano ai cazzoni come il tipo in oggetto.
Saluti,
Alex
-- 
Alex75

 peccato che far abrogare la legge ha bisogno del tuo voto,
No. Per far abrogare la legge deve convincere ad esempio i parlamentari
della Lega a votare l'abrogazione, anche se Rutelli non dovesse essere
d'accordo, eventualmente anche comprando i voti di tali parlamentari e di
tutti gli altri che gli consentano di abrogare tale legge, come sta
facendo attualmente qualcuno con altri parlamentari (anche se quello
attuale magari la compravendita la fa per altri motivi).
Se gli dassi il mio voto "a scatola chiusa", questo varrebbe quanto quello
di chi ha votato Scilipoti alle ultime elezioni.
Possibile che nemmeno di fronte all'evidenza piu' evidente si riesca a
capire ?!
Mah ...
Ciao,
Marco.


 devoloper.
o magari semplicemente belle fighe ....


 :-)))
ho dimenticato di dire che il codice era immondo, ma vabbe poteva anche
essersi capito :-))


 o magari semplicemente belle fighe ....
Gli intemediari che ho conosciuto io per lo piu' avevano i baffi e/o erano
calvi. In altri casi non pagavano (ed erano comunque appartenenti al
genere maschile). Attualmente effettivamente la bodyrentallara e' una
donna, ma ha figli che avranno circa 20 anni.


 Lungo, ma si toccano anche temi discussi prima della dipartita di Cul.
Pi� che lungo, GROSSE....  :)
Abbiamo passioni in comune....

 Abbiamo passioni in comune....
Servono per testare la capacità di concentrazione durante la lettura di un 
articolo tecnico.
Se le fissi per più di 3 secondi, hai fallito il test :-) 

 Alex75

 meravigli davanti a un cumulo di pesanti ovvietà-
"War Games". Comprai il laser disc nei lontani anni 90. E' ancora uno dei 
miei film preferiti. Erano i tempi in cui programmavo in assembly e C. 
Io, pero', sono cresciuto.
Saluti,
Alex.
-- 
Alex75

 miei film preferiti. Erano i tempi in cui programmavo in assembly e C.
Ed ora fai il PM.... :-)))