Newsgroup: it.lavoro.informatica
Titolo: Gli architect e la programmazione

Stamattina ho scambiato un paio di email con un amico di mio fratello,
neolaureato e da poco entrato nel mondo del lavoro, che mi chiedeva
qualche consiglio su una nuova posizione che gli hanno offerto, in
considerazione del fatto che il suo obiettivo di carriera è quello di
diventare un IT architect si da "programmare molto meno e progettare
[di più]".
Questa dei software architect che programmerebbero meno è sinceramente
uno dei miti più strani che di tanto in tanto mi tocca ascoltare o
leggere: nel mondo reale, tutti gli architect che ho visto al lavoro,
programmano da mane a sera, parlano di programmazione quando siamo a
pranzo o in un pub, pensano con il pugno sotto il mento come i
filosofi e se gli chiedi a che pensano ti rispondono chiedendoti che
ne pensi di una certa soluzione ad un problema di programmazione,
leggono in continuazione libri sulla programmazione scritti da
programmatori, usualmente hanno lavorato per 5+ anni all'interno di un
team dove si sono conquistati il posto dimostrando di sapere
progettare, costruire e guidare lo sviluppo più di un'applicazione,
spesso costruiscono loro stessi il team, gli vengono loro
continuamente affidati compiti come il trasferimento di conoscenze
(mentoring) verso i nuovi membri (programmatori) del team o la
creazione di prototipi ed ovviamente hanno la parola finale o comunque
sono determinanti sulla scelta delle librerie, tecnologie e
quant'altro.
Se l'aspirazone è programmare poco, mi sembra che la posizione di
architect non sia quella a cui si dovrebbe aspirare, o c'è qualche
peculiarità di come è intesa la posizione in Italia che mi sfugge?
--
ale
http://ale.riolo.co.uk

 [di più]".
Mandalo gentilmente a cag*re. Il programmatore coda, coda, coda. Anche il più 
alto in grado alla fine. Altrimenti passi a fare altro.
-- 
__________________________________
Luc (36, CO)
25 years uninterrupted programming
__________________________________

 peculiarit� di come � intesa la posizione in Italia che mi sfugge?
Vedi sopra.
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 e' quello che progetta "il sistema", non "il software".
No, lui intendeva proprio il software architect, dal resto del
discorso si evinceva chiaramente.
--
ale
http://ale.riolo.co.uk

 alto in grado alla fine. Altrimenti passi a fare altro.
Gentilmente gli ho fatto notare che nella mia esperienza (ed a questo
punto ne ho visti tanti) il software architect non fa altro che
programmare, e che l'obiettivo era non programmare, poteva fare altro,
a.e. il business analyst :)
--
ale
http://ale.riolo.co.uk


wrote:

Per tua fortuna sei stato assente dall' Italia abbastanza da
dimenticarne alcune deformazioni :)
Allora, io credo che questa ridicola figura dell' architetto che non
programma sia dovuta principalmente a due ragioni:
1) un gran numero di persone che hanno intrapreso la programmazione
per necessita' e non per passione e quindi non amano veramente
programmare e che quindi ha come scopo quello di smettere di
programmare, non di programmare meglio.
2) la bassa considerazione ( e qui ci sarebbe da discutere a lungo sui
motivi ..) in cui viene tenuto un programmatore in Italia. In sostanza
viene considerato come un aggiustatore di lavatrici, un "tecnico" nel
senso dispregiativo del termine, cioe' uno che sa fare un po' di
cosette pratiche che chiunque saprebbe fare se non avesse altre
possibilita'.
Questo definisce la dannosissima equazione "progresso in carriera =
smettere di programmare", che porta danni notevoli allo sviluppo di
progetti che vengono "progettati a tavolino" da gente che non sa o non
vuole testare e aggiornare le proprie idee con il codice.

 vuole testare e aggiornare le proprie idee con il codice.
Ma davvero esistono realtà del genere?
O_o
Ciao,
Giulio
--

 possibilita'.
Il mese scorso mio padre ha chiamato un elettricista che gli facesse un
lavoro di un'ora circa. L'elettricista ha chiesto poco meno di 40 Euro+iva
(credo fossero 45 Euro iva inclusa).
Se mi pagassero come "un tecnico" sarei ben contento di farmi considerazio
un "tecnico" nel senso dispregiativo del termine.
Ciao,
MArco


 Ma davvero esistono realt� del genere?
Per quanto a mia conoscenza le realta' del genere sono praticamente tutte
quelle con numero di dipendenti >= 50 (e anche molte di quelle con numero
dipendenti < 50)
Ciao,
Marco


 a.e. il business analyst :)
Contento di esserti stato utile... :) 


 architect proprio per le peculiarità sopra esposte.
Sinceramente non so come dirtelo, ma tutti i software architect con
cui ho avuto a che fare lavorano sua sponte 50-70 ore a settimana,
fanno commit a mitraglia Sabato e Domenica, se arrivano tardi in
ufficio è perchè hanno lavorato tutta la notte, e se c'è qualche
problema serio sono i responsabili ultimi della situazione e vivono in
stato di stress costante ..
D'altra parte hanno (meritatamente) retribuzioni a partire da £60k
lordi escluso tutto (direi tra £80k-£100k in media), ma lavorano come
crasti con la lama del boia sempre ad un passo dal collo, spesso in
condizioni psicofisiche borderline (una volta ne ho avuto uno che si
beveva una confezione da 6 di red bull al giorno ..).
--
ale
http://ale.riolo.co.uk

 Contento di esserti stato utile... :)
Gli avevo già risposto prima di iniziare il thread, ma grazie
comunque :)
--
ale
http://ale.riolo.co.uk

 
Decisamente s�, e anche con numero dipendenti < 5 (non ho dimenticato lo 
zero).
-_-

 usualmente
BIIIIP! Errore! :)
(tanto ti han già risposto e tu hai già risposto al tuo interlocutore 
iniziale, quindi...)
-- 
Vide

 clima dove nessuno m'imponeva scadenze,
se fai un lavoro di prototyping o qualsiasi altra attivit� propedeutica 
al lavoro di altri, certo nessuno ti impone scadenze ma in realt� le 
scadenze ce l'hai e sono dettate dal fatto che non puoi avere persone 
ferme ad aspettare che tu finisca. e queste scadenze sono anche assai 
pi� rigorose e strette perch� il danno si ripercuote ad effetto domino.
certo che se hai bisogno di una pistola puntata per rispettare i tempi 
sei davvero un guga-guga coi fiocchi.


Prevedo la sua risposta: "Impossibile, quei software architect sono
workaholic, io mi sono trovato benissimo in quel ruolo lavorando 17
ore a settimana scelte come pareva a me, finchè il cliente non mi ha
condotto fuori dall'azienda facendomi una vite all'orecchio, lo
schiavista!"

 schiavista!"
lol stavo bevendo mi hai fatto annaffiare la tastiera! :-D

 Prevedo la sua risposta: "Impossibile, ..
A me sinceramente la cosa un po preoccupa per il povero Osid, la mia
esperienza personale (per non parlare degli hearsay al pub) cozza
veramente frontalmente con le sue aspettative, anche a lui IMVHO
consiglierei la strada del business analyst/project manager/product
manager/strategic manager se non vuole programmare tutto il giorno e
buona parte della notte per il resto dei suoi giorni :))
--
ale
http://ale.riolo.co.uk

 schiavista!"
LOL!
-- 
Vide

 beveva una confezione da 6 di red bull al giorno ..).
Io Red Bull non ne bevo, ma per il resto avrei tranquillamente 
potuto essere io fino al 2003-2004, tranne che per la retribuzione che
poteva essere considerata "buona" nel periodo 2001-2003 (anche se meno
buona di quella di altri) e' andata poi progressivamente diminuendo, almeno
come potere d'acquisto (ma non solo). Solo dopo tale diminuzione ho in
qualche modo deciso di passare gradualmente tra quelli che di codice non
ne scrivono, se non molto raramente e per puro diletto personale, mai per
il datore di lavoro (anche se l'occasione per passare definitivamente
dalla parte di coloro che non scrivono codice e' stata molto casuale)


 
Tipo scrivere cazzate sui ng...

 [di pi�]".
mmmm comincio a capire...
leggono il curriculum e mi chiedono ma lei
proviene dal settore ospedaliero?
IT architect!!! c@##o! non analista,
fidec devo aggiornarmi!!!

 leggere: 
Io penso, innanzitutto, che il termine "architetto" sia un appellativo 
di cui oggi si abusa molto, anzi troppo. In generale, comunque, un 
architetto e' una persona che dovrebbe avere:
1) (Soprattutto) una *conoscenza approfondita* del dominio del problema;
2) Una consolidata esperienza nella progettazione e sviluppo SW, quindi 
spesso un'anzianita' lavorativa o nel contesto superiore alla media;
3) Una buona conoscenza di metodologie e tecnologie;
4) Una visione di insieme del progetto, di piu' alto livello, che prima 
di tutto conosca e determini le varie interfacce tra i componenti di un 
sistema, che singolarmente possono essere visti come "scatole grigie" o 
"nere".
5) Spesso, ma non necessariamente, anche compiti di coordinamento di un 
gruppo di lavoro.
Questi requisiti penso siano generalmente applicabili: poi ci sono anche 
una serie di fattori importanti intimamente legati al contesto. Ad 
esempio, in un progetto grande, magari sviluppato da diverse decine di 
persone, e' probabile che l'architetto di sistema sia quasi un lavoro a 
tempo pieno, abbastanza slegato dalla programmazione (anche se, 
ovviamente, questa deve fare sicuramente parte dell'esperienza di chi 
ricoprira' quel ruolo); in progetti piccoli, invece, e' facile che 
l'architetto sia anche impegnato in prima linea nelle attivita' di 
sviluppo.
Per fare un altro esempio, in sistemi in cui il software ha forte 
interazione con l'hardware, quali quelli di automazione, sara' 
necessaria una figura di "architetto di sistema", con competenze non 
limitate al software.
Comunque sono d'accordo: in generale diventare (software) architect non 
significa, in generale, abbandonare la programmazione, ma integrarla e 
affiancarla a compiti piu' di progettazione di sistema.
TheStar

 [di più]".
Ci sono due possibili spiegazioni.
La prima è che non abbia la ben che minima idea di cosa faccia e cosa
sia un architect. Ed è molto probabile visto che in Italia non c'è
conoscenza di metodologie e metodi di sviluppo, si va sempre alla
giornata alla "lo so fare meglio io che sono un Dio".
Ti basti vedere li 3d sul pair programming, che ti può piacere o meno,
puoi pensare che sia fuffa, ma che comunque è una tecnica conosciuta
ed usata nel mondo da almeno un decennio, pubblicata su IEEE Software
ecc...
La seconda è che l'abbiamo messo a fare stampe ( o classi j2ee )
tutte uguali senza analisi e senza alcuna libertà di azione, in quel
caso intende il "progettare" pensare a quello che dovrà fare,
impostare il programma ecc.. ed è vero, da architect oltre che
scrivere si pensa anche, o almeno si dovrebbe.

 Tell me more... :-)
Per quello che ho visto e vedo, le quattro posizioni sopra centrano
molto più i PalettOsid rispetto a quella di software architect.
--
ale
http://ale.riolo.co.uk

 --

 Di cosa parliamo? Software developer o IT architect?
Software architect. 50-70 ore di lavoro a settimana, tutta la
responsabilita o quasi sulle scelte tecnologiche e sulle assunzioni
nel team di sviluppatori, se c'e' qualche non tecnico che propone
tecnologie strane o stralunate, tocca a lui mandarlo a quel paese,
anche se il non tecnico siede nel CdA, se qualcosa di molto tecnico va
a male, la sua testa e' la prima a rotolare.
E tra l'altro, arrivarci a fare il software architect non è mica rose
e fiori ..
--
ale
http://ale.riolo.co.uk

cui ho avuto a che fare lavorano sua sponte 50-70 ore a settimana,
Ora senza arrivare agli eccessi di Osid 70 ore alla settimana sono 14 ore al 
giorno.
Ti pare normale rinunciare alla vita completamente per lavoro? A me verrebbe 
qualche dubbio.
Uno dovrebbe guadagnare di piu' (*meritandoseli*) se ha le pa**e non se 
lavora ennemila ore al giorno... se no mi sembrano piu' che altro 
straordinari mascherati che un premio alle competenze.
Stef

 peculiarit� di come � intesa la posizione in Italia che mi sfugge?
Un detto americano dice:
"architect-dont-code"
e' il miglior pattern per far fallire un progetto :-)
Nicola


 Come lo spieghi ciò?
Sei prevenuto, leggi senza capire, magari io traduco dall'inglese
troppo letteralmente, fai tu ..
--
ale
http://ale.riolo.co.uk

 
http://ale.riolo.co.uk
E' chiaro che prima di diventare "Software Architect", ma che io chiamerei
pi� esperto di dominio, di codice deve masticarne un bel po'. Cmq, nei
prossimi anni, visto il proliferarsi di piattaforme e relative
architetture, quasi totalmente portabili ( .NET/Mono, Java, Php), �
ragionevole pensare che di codice se ne scriva sempre meno, utilizzando
tecniche di programmazione generativa o un'approccio pi� orientato ai
modelli rispetto al passato. Ovviamente parlo di domini enterprise o web,
dove i processi non sono rigorosi come in quelli molto pi� critici, come
quelli avionici o aerospaziali. Quindi, partendo dall'architettura pi�
modello di dominio, si genera completamente il codice di infrastruttura
pi� una porzione (che tende sempre al minimo) customizzabile via codice. 


 lavora ennemila ore al giorno...
Tutti i software architect con cui ho avuto a che fare o che mi sono
stati descritti da terze parti erano ottimi professionisti, persone
piene di talento, e probabilmente centravano in pieno quello che Osid
intende come workaholic.
Il punto che volevo fare, non è quello di giudicare o giustificare la
vita che queste persone si sono scelte e fanno, ma quello di far
notare che:
1 - programmare la propria carriera con l'obiettivo di diventare
software architect perchè a quel punto si potrà programmare poco o
niente, è usualmente una scelta dissennata, perchè i software
architect scrivono codice da mattina a sera, e quando non lo scrivono
lo pensano, e quando dormono lo sognano.
2 - programmare la propria carriera con l'obiettivo di diventare
software architect perchè questi lavorerebbero poche ore a settimana e
non sarebbero sottoposti a pressioni o stress è anche più dissennato,
IMVHO nelle aziende IT solo i CTO potenzialmente lavorano di più,
rischiano di più il posto e sono più stressati e sottoposti a più
pressioni.
Tra l'altro suggerivo a Osid 4 posizioni meno stressanti, ma lui non
ha capito o non ha voluto capire il suggerimento.
--
ale
http://ale.riolo.co.uk

 più una porzione (che tende sempre al minimo) customizzabile via codice.
La costruzione di quel plumbing di cui parli è esattamente la
descrizione del lavoro che ho visto principalmente svolgere a tutti i
software architect con cui ho avuto a che fare negli ultimi 5 anni, e
che ho fatto anch'io quando mi sono trovato a svolgere quel ruolo per
brevi periodi (l'ultima volta 4-5 mesi nel 2007).
--
ale
http://ale.riolo.co.uk

 più una porzione (che tende sempre al minimo) customizzabile via codice.
Permettimi di essere un po' scettico su questa cosa :^)
Sono più di vent'anni che sento parlare di strumenti che dovrebbero
servire a generare il codice (CASE, poi RAD, poi scaffolding, ecc.
ecc.) ma alla fine quello che ti viene fuori non è *mai* quello che ti
serve, e devi metterci pesantemente le mani. Certo gli strumenti
evolvono e ci sono sempre più ausili per ridurre i tempi di sviluppo,
ma parallelamente i sistemi diventano sempre più complessi (per stare
dietro alla sempre crescente richiesta di feature), per cui alla fine
dei giochi il tempo di sviluppo è sempre massiccio in un progetto IT
di una certa importanza.
bye!

 pressioni.
Confermo che i pochi SW Architect veri e bravi che ho incontrato fino a
ora lavoravano nel seguente modo :
1.  LAvorano piu' ore degli altri developer
2. Tutti i task in cui un developer si blocca/ha dubbi/e' in
difficolta'/ha delle idee da discutere eccetera l'Architect scende in
campo per risolvere, se necessario con suggerimenti/decisioni e basta,
altrimenti programmando.
3. Il lavoro PRINCIPALE dell'architect e' progettare l'architettura, anceh
fino fino alle interfaces/pattern/impianto generale
4. Tipicamente nei  progetti del mio ambito l'Architect si carica di
creare il project ( ant/maven) e manutenerlo.
5. In Italia tipicamente l'Architect non viene pagato di piu' dei
developer perche' lo si incetriola con il fatto che puo' metterssi il
cappillino nerd/geek - architect, un bel biglietto da visita e via lavora
il doppio senza chiedere gli straordinari.
Spesso e' invidiato dai alcuni developer , tipicamente i giovani nerd ceh
vogliono fare carriera e prendere il suo posto, tartassato dai
PM/dirigenti e se non e' protetto dal cliente diventa il ground zero della
battaglia e si piglia le telefonate / menate del mondo intero.
Se uno cosi' non sa programmare mi metto a ridere subito o aspetto ?
Ricordiamo che programmare e' come uno sport, basta non programmare 6mesi
-1 anno mesi e si perde la forma subito.
Andando oltre e studiando come modelli i super-team migliori del mondo
tipo Jboss, Liferay, o quello che volete, di fatto tutto il team sono
architect, e poi ognuno prende il ruolo di architect su un singolo
progetto.
Questo e' il modello a cui si deve aspirare imho, tutti architect e
senior. I team di soli architect che programmano sono magnifici, possono
in pochi mesi scrivere qualsiasi software :-)
Nicola


 modello di dominio, si genera completamente il codice di infrastruttura
Si ciao, sono 50 anni che ci provano. Di solito, quando arrivano una
complessità mostruosa, esce qualcosa di nuovo e si resetta tutto.
PS : nelle applicazioni reali, mai visto un "modello di dominio" che
funziona, sempre sul DB si torna: Ovviamente previo fallimento del
progettone infarcito di consulenti ed architetti di ultima
generazione.

 bye!
Il problema con i CASE e sistemi vecchi � che tendono ad essere troppo
generici, ossia cercano di risolvere problemi su domini che non sono
specifici, da qui il 'dogma' one size fits-all. Questa assunzione � stata
completamente irrealistica nell'uso pratico. Tipicamente l'80%
dell'applicazione poteva essere creata piuttosto velocemente, ma il
rimanente 20% richiedeva l'80% dell'effort totale. La lezione direi che �
stata imparata e i vari tool di modellazione integrati in Eclipse possono
essere un valido aiuto [EMF + xtext], quindi capisci che puoi crearti il
*tuo* modello e generare il *tuo* codice. Il fatto che sono 50 anni che
dicono sempre la stessa storia non ne pregiudica un insuccesso a priori.
In questo caso, per modello di dominio non intendo le classi che formano
il modello persistente (anche se mi sembra che con EJB3 le cose siano
molto migliorate, per .NET e altri non so).


> Ma davvero esistono realt� del genere?
Eccome!

 IMVHO nelle aziende IT solo i CTO potenzialmente lavorano di più
d'accordo su tutto quello che hai detto fino ad 
ora.ma
 che il CTO si
faccia piu' il mazzo di un architect... non scherziamo su..

- con sede di lavoro a Milano citt� o immediato hinterland;
Sai temo che con queste limitazioni uno non possa ambire a nessuna 
progressione di carriera in nessun campo, a meno di non essere ben 
ammanicato o di sapere leccare i culi in modo eccezionale (o se donne darla 
alle persone giuste).
Per carit�, anch'io preferisco (e ho) un lavoro come tu descrivi, limitando 
il pi� possibile lo stress, perch� la vita ne ha gi� abbastanza di suo senza 
doverne aggiungere, anzi ne vorrei uno ancora meno stressante, ma so anche 
che non far� mai carriera, e la cosa mi sta bene.
Ma tralasciando gli ammanicati, leccaculo, ecc, che sono l'80%, tutti gli 
altri che hanno fatto carriera e sono arrivati a ricoprire posizioni 
dirigenziali (in ambito tecnico e non) sono persone che, oltre ad avere le 
capacit�,  si sono fatti un mazzo tanto sul lavoro, sacrificando anche parte 
della vita personale. Per carit�, io non lo farei, ma sono scelte legittime.

 Ma davvero esistono realtà del genere?
Eccerto.
Il bello e' che chi ne fa primariamente le spese non sono i "ciovani"
programmatori neolaureati ma le aziende che usufruiscono dei servigi
IT.
La frase che senti spesso nei corridoi delle grandi aziende di
telecomunicazioni italiane e' "al cliente importa soltanto che
l'applicazione giri e funzioni".
Gia', dopo mesi di analisi e progettazione tutta up-front, con delle
metodologie che o e' la vecchia waterfall oppure niente, ci si ritrova
con un sistema che funziona...ma con spaghetti code e stuzzicadenti
messi li' a reggere l'accrocchio che si e' andato formando.
Da notare che l'analisi e la progettazione up-front viene quasi sempre
fatta dagli omini di 4cc3ntur3, "non tecnici e orgogliosi di non
esserlo" .
Bah...contento il cliente, contenti tutti. Peccato per i clienti
(quelli plebei) che sono costretti a combattere con i call center per
farsi dare indietro i soldi spesi per dei servizi non attivati,
sollecitare attivazioni adsl andate "perse" dal sistema, credito
residuo azzerato per oscuri motivi e via dicendo.

 faccia piu' il mazzo di un architect... non scherziamo su..
Nella mia esperienza personale sì, ma magari ho una visione ridotta
della cosa.
--
ale
http://ale.riolo.co.uk

 senior.
Io non ci trovo nulla di male ad avere degli junior, o anche dei
principianti, basta che siano svegli, volenterosi di apprendere e
capaci di diventare produttivi in tempi decenti, IMVHO sono un plus.
--
ale
http://ale.riolo.co.uk

 potenzialmente i requisiti per ricoprirle?
Da come descrivi la tua esperienza pregressa, ritengo tu potresti
avere l'esperienza necessaria per proporti come business analyst/
project manager/product manager (3 su 4). Ovviamente non posso sapere
se tu ne abbia anche le necessarie competenze e capacità.
--
ale
http://ale.riolo.co.uk

 molto migliorate, per .NET e altri non so).
non parlavo a livello di dettaglio, ma generale. Le singole
implementazioni cambiano poco.
bye!

> Ma davvero esistono realt� del genere?
Purtroppo si

 lavoro solo come software developer...
Non capisco perche' si snobbano i developer. Il lavoro di developer che mi
e' sempre piaciuto sto vedendo oggi che e' forse uno dei piu' belli in
assoluto e se becchi il progetto giusto guadagni il triplo di chiunque
altro :-)
ciauz Nicola


 alehttp://
ale.riolo.co.uk
La peculiarita' che salta subito agli occhi leggendo il tuo post
e' che la posizione di architect e' una posizione che delinea
una certa esperienza, che certamente un neolaureato non ha.
Ora non si capisce se e' quella che gli hanno offerto (mi pare strano)
oppure se lui fra dieci o vent'anni invece che star li' a fare
il programmatore, dato che si e' laureato, capisce che
e' una strada lunga e col tempo vorrebbe arrivare
ad altro.

 ad altro.
No, ovviamente non gli hanno offerto di lavorare come software
architect. :)
Mi chiedeva se accettare una data posizione, dato che il suo obiettivo
di carriera era tra 5 o 6 anni diventare software architect.
Quello che mi colpiva era il fatto che pensava, come tanti altri in
fondo, che i software architect programmino meno (di quanto faccia lui
ora come programmatore neolaureato).
Io quando devo parlare con i miei architect, di solito non arrivo a
staccargli le mani dalla tastiera, ma poco ci manca :))
--
ale
http://ale.riolo.co.uk

 staccargli le mani dalla tastiera, ma poco ci manca :))
Che i sw architect programmino meno e' un po'
una chimera che dipende molto dal posto dove finisce
(e se ci resta a lungo)... un data architect comunque
deve avere un'esperienza da dba e/o programmatore sql...
Concludendo : se vuole fare il sw architect "da grande"
sara' meglio che si rimbocchi le maniche e cominci
a fare il programmatore per qualche anno, direi.

 *tuo* modello e generare il *tuo* codice. Il fatto che sono 50 anni che
Questi modelli tralasciano 2 aspetti a dir poco fondamentali, per
applicazioni gestionali o web :
- I dati sono tabulari
- L'interfaccia costa l'80% del tempo di sviluppo dell'applicazione
Il primo fatto è indiscutibile, i dati sono tabelle, non oggetti. Gli
oggetti sono un modo fantastico di organizzare il codice, ma non
l'informazione. L'utilizzo di un modello che si discosta da tale
formato, ad esempio usando funzioni e più dimensioni, rende difficile
accedere all'informazione al di fuori della tua applicazione ed è un
prezzo troppo grande da pagare.
Sull'interfaccia invece si può non essere d'accordo ed ovviamente
dipende moltissimo dal tipo di applicazione, ma in generale è lì che
lavorare bene rende l'applicazione una buona applicazione.

 Una posizione per cosa quindi ? (scusa non ho letto tutto il 3d)
Non ricordo di averlo scritto, non credo sia rilevante per il tema
("perchè taluni credono che i software architect non programmino?")
del thread.
BTW, gli offrivano di andare a lavorare nel QA (ma almeno lì era
cosciente che la posizione contrastava con i suoi obiettivi di
carriera).
--
ale
http://ale.riolo.co.uk

vita completamente per lavoro.
Ma qui siamo d'accordo eh :)
Stef 


Sono d'accordo ma in realta' ci sono delle considerazioni da fare:
1. l'architetto spesso e' un ex-programmatore eccellente con una
passione smodata per il suo lavoro; lavorava 14 ore da programmatore e
lavora 14 ore da architetto, anche perche' spesso non sa che fare di
altro. Ha sete di conoscenza e passa il tempo libero a trovare il
silver bullet (la pietra filosofale) dell'ingegneria del software. Non
e' propriamente un workaholic, IMO. E ne conosco qualcuno che, se non
fosse per il mutuo da pagare, lavorerebbe anche gratis.
2. Ci sono anche architetti "agili". Quelli cioe' che, fedeli al dogma
8 ore x 5 giorni a settimana, adattano i propri lavoro e produttivita'
a quel ritmo, utilizzando processi agili. E "impongono" i ritmi
all'intero team.
3. molto lavoro dell'architetto e' anche di tipo politico-negoziale e
quindi in 14 ore di lavoro probabilmente un paio se ne vanno in
chiacchiere:) Oltre al fatto che e' una professione in cui non si
avvitano bulloni in catena di montaggio e probabilmente 12 ore di
lavoro equivarrebbero ad 8 piene.
4. un enterprise architect e' diverso da un software architect. Il
primo ha responsabilita' enormi. Le responsabilita' del software
architect, invece, sono grandi ma i rischi sono pochi, nel senso che
un disastro puo' capitare soltanto se uno si improvvisa software
architect.

 alehttp://
ale.riolo.co.uk
Premesso che come PM di progetti di sicurezza continuo (con gioia) ad
occuparmi di sistemistica e networking, quando ancora mi occupavo di
billing continuavo comunque a sfornare script oracle uno sull'altro
eppure mi vendevano come ANALISTA SENIOR - questo non perchè non
facessi analisi, ma perchè tra un documento di progetto da scrivere
con il mio responsabile di allora we un meeting c'era SEMPRE lo script
da consegnare, considerando che io ero uno dei pochi nel gruppo che
conoscesse la base dati di quella maledetta applicazione, quindi un
BILLING EXPERT dell'epoca.
L'amico di tuo fratello è semplicemente un'illuso.
Come detto da altri se vuole evitare di programmare passasse nel
reparto marketing/presales. Di rimando, lì dovrai continuare a
scrivere requisiti funzionali e documenti di analisi!!!