Ivar Jacobson: ecco cosa non insegnano ai programmatori

Il ragionamento regge lo stesso. Non necessariamente chi programma ha skill che permettano di essere team-leader o è in grado di apprenderle.


Se usano un approccio waterfall hanno ben poco da spartire con Jacobson.

L'articolo di cui si discute però non è rivolto ai PM, che non sono dei tecnici, ma ai programmatori/ingegneri del sw.
Di questi ultimi si discute contestando, nello specifico, la visione di chi pensa che sulla base di una esperienza puramente accademica, e senza aver scritto una riga di codice nella vita, si possa ingegnerizzare un software.



Non ho detto che i requirements non sono importanti, ma tra le cause di fallimento di un progetto, sia in letteratura che nella pratica, vengono sicuramente all'ultimo posto.
In special modo se poi hai un committente rompiballe come quelli che ho conosciuto io. In tal caso stai sicuro che l'auto uscirà del colore giusto ( che nel frattempo sarà stato cambiato in corso d'opera 57655 volte ).



Purtroppo no, mi devi spiegare tu che c'entrano i design pattern con l'edilizia.
Non sto sfidando nessuno eh, voglio capire sinceramente perchè sta storia del muratore e dell'architetto esce fuori praticamente sempre quando si parla di sviluppo sw, mi incuriosisce il suo fondamento.

Io invece credo sia rivolto proprio a tutti.
In quel che affermi c'è una distorsione (italiana) della figura del project manager.
In Italia si è creato l'artifizio del project manager per cui è a capo di un progetto o di un team ma non ha (sufficiente) know-how tecnico.
Cosa molto vera nelle grandi aziende di consulenza, dove si tende ad una struttura fortemente piramidale.
Il che per me però resta una cosa priva di logica perché per rimanere alla casistica edilizia è come se un architetto o un ingegnere non conoscessero i materiali utilizzati in una costruzione, come questi e le misure di portanti ed altri elementi della stessa inficiano sulla stabilità, resistenza a fattori esterni ecc.

Ma all'estero non funziona così.
Il Project Manager che in realtà non esiste ma viene chiamato spesso Team Leader è uno sviluppatore.
Se vedete i webcast dei vari Channel MSDN vi rendete conto che tutte le persone che ricoprono incarichi a più alto livello nello sviluppo software di un prodotto sono anch'essi sviluppatori.
Gli stessi Brin e Page sviluppano al fianco dei dipendenti.
Non solo è logico, ma è anche una forma di abbattimento della differenza sociale tra sottoposto e superiore. Se lui è lì è perché ci è arrivato facendo quel che fai tu, magari prima di te e forse meglio di te.
Ciò non toglie che puoi arrivare un giorno a ricoprire quell'incarico.
E' molto più meritocratico e democratico.
Ed ecco la differenza sostanziale che separa l'Italia dall'estero, mondo anglosassone in primis.




Curioso anche io

Dunque come al solito sta uscendo un macello di discussione .

1) ing informatica non è solo programmazione , un ingegnere informatico che fa il solo lavoro di programmatore è riduttivo . E questo lo disse persino Mandrioli alla mia proclamazione di laurea triennale (anche se capisco questo vada quasi a detrimento di quanto ho appena affermato :asd

2)il polimi in 2 righe cosa scrive di ing informatica :


e ancora



Anche solo guardando il piano di studi si capisce che le competenze di un ing. informatico sono ben più ampie della sola programmazione (che poi vabbè può essere più o meno complessa etc .)

Risulta anche chiaro , sempre guardando i piani di studi, che un ing. informatico debba sapere cos'è la programmazione , infatti è fatta in alcuni esami obbligatori ,anche se viene detto esplicitamente che i linguaggi di programmazione si suppone uno se li impari in seguito a seconda di quello che più si adatta all'applicazione da realizzare.Cioè ti insegno java e C e le idee alla base , poi un domani se ti serve imparare phyton te lo impari te per conto tuo , le capacità per farlo rapidamente dovresti averle.

La programmazione per un ing. non è lo scopo finale , non studia per imparare a programmare , bensì impara a programmare per risolvere problematiche e per implementare algoritmi e modelli .

L'idea è che c'è un problema e l'ing. informatico utilizza le sue conoscenze per risolverlo. Ad esempio potrebbe essere che fastweb mi contatta e mi dice che vuole una valutazione delle prestazioni della sua rete e delle ottimizzazioni possibili e magari pure la realizzazione di un software per modellare il suo sistema da utilizzare per ulteriori valutazioni e previsioni.
Oppure può anche voler dire valutare diverse architetture e diverse soluzioni software e sceglierne una per poi implementarla .

Per cose del genere cosa fate chiamate il programmatore diplomato anche con 10 anni di esperienza? No chiamate l'ing. informatico (ma anche telecomunicazioni o altro eh), poi l'esperienza o meno è un altro discorso: è chiaro che il neo laureato andrà affiancato da qualcuno esperto , farà gavetta etc etc , ma le competenze richieste da problemi del genere richiedono un approccio ingegneristico.

Ovviamente tali problematiche possono avere difficoltà molto diverse e criticità molto eterogenee.

Infine aggiungo che è scontato che appena uscito dall'università ci sia cmq molta esperienza da fare e molto ancora da imparare prima di fare qualcosa di molto serio . Nessuno pretende di uscire dall'uni e diventare project manager per un progetto importantissimo .
Poi vabbè tra questo e passare il tempo a scrivere codice e basta ci sono tante via di mezzo.


P.S.
Cmq se non c'è chiarezza qui , su un sito tecnologico, su quali siano i compiti e le mansioni di un ing informatico non mi stupisce che poi le aziende (specialmente italiane) li prendano e li mettano a programmare e basta senza sfruttarne le peculiarità o non capendole . Poi vabbè è anche vero che l'approccio ingegneristico è utile in moltissimi campi, pura programmazione inclusa , però....

P.P.S.
Io parlo di ing. informatica . Ing. del software io la conosco solo come una delle materie all'interno del corso di studi di ing. informatica . In questo 3d sono state usate quasi a sinonimi , ma per quanto mi riguarda non lo sono , quindi preciso onde evitare fraintendimenti.

PPPS
Scusate i numerosi refusi , ho scritto molto velocemente

Si', ci puoi portare un esempio contrario?



Non capisco perche' la stai mettendo sul personale. Avrai finito gli argomenti.
Qui non si sta vantando e non sta sboroneggiando nessuno: ci limitiamo a riportare la nostra esperienza e a discuterne. Per cortesia comportati in maniera civile e non lasciarti andare ad uscite cosi' puerili.

I Design Pattern nascono per l'edilizia, per mano di tal Christopher Alexander con il libro A Pattern Language.
La similitudine tra edilizia è meno campata in aria di quanto sembra.
Ti porto un esempio che amo particolarmente e che ho spesso usato parlando con commeciali e pm
Se tu devi tirare su un piccolo muro a secco, chiami un muratore e lo fai fare.
Se devi aggiungere una stanza a casa tua, pobabilmente ti appoggerai ad un qualunque buon geometra per il progetto ed a una qualunque ditta edile per il lavoro pratico.
Se vuoi costruire una villetta su un tuo terreno, probabilmente cercherai un geometra o architetto che abbia esperienza e una impresa edile che abbia costruito altre villette.
Nel momento in cui tu volessi costruire un palazzo di 10 piani cercheresti altrove.
Non parliamo per un grattacielo, a quel punto la struttura dovrebbe essere davvero ben organizzata, onde evitare problemi disdicevoli.
Questo perchè le complessità non sono lineari.
Non è detto che chi sa tirare su un muro a secco, sia in grado di metterne insieme quattro e fare una stanza.
Eccetera eccetera fino al grattacielo.
Per quanto riguarda i dp, normalmente in edilizia per risolvere problemi comuni si tendono ad usare soluzioni conosciute e rodate.
Esattamante come si dovrebbe fare con l'informatica.
La similitudine tra edilizia e informatica nasce dal fatto che stringi stringi si tratta sempre da costruire/riparare.
Le figure professionali dell'edilizia trovano sempre una similitudine nel mondo dello sviluppo, tanto quanto le problematiche.
Spero di essere stato esauriente, e scusa per il giochetto di prima.
Se ho detto qualche m*****ata non torturatemi.

a me pare calzante come paragone.

C'e' una differenza fondamentale fra Ingegneria Civile/Edile e Ingegneria del Software: la prima scienza ha migliaia di anni di esperienza alle spalle. La seconda no.

Da qui in poi le metodologie di soluzione dei problemi divergono totalmente e le analogie cadono, perche' puoi stimare con un errore spesso inferiore al 5% il costo di un ponte o di una casa, ad esempio, mentre se riesci a stimare con un errore inferiore al 100% il costo di un software stappi le bottiglie di champagne.

Non sono le metodologie ma i processi che differiscono. Anche se stiamo a spaccare il capello sui sostantivi.
Questo perchè le specifiche di un progetto edilizio se cambiano lo fanno prima della loro effettiva messa in opera.
E per questo si approccia a cascata. Cosa che nel software equivale al suicidio.
Nel software le specifiche sono sempre soggette al cambiamento, per definizione. E in qualunque fase del progetto.
Per curiosità, le stime raddoppiano sistematicamente? Capisco un 20% che ci può stare ma può essere previsto, ma 100% mi sembra tantino.

A parte l'uso dei sostantivi, sul resto sono d'accordo con te.