Sunday, July 16, 2006 

Quantitative Design Methods

Lets face it: most people do not design software; they code their way through it. There are many (bad :-) reasons for that, including the trivial fact that lot of decent coders are not inherently good at designing software. But leaving those reasons aside, there is an important difference between software and other engineering disciplines. In other disciplines, one of the reasons to go through a design phase is that you can get some quantitative data to back up your decisions. Those quantitative data can be useful to answer some questions, like "if you build that bridge with that shape and using those materials, how much weight / wind / etc can it sustain before breaking", or "if we place components this way on the PCB, what would the thermal distribution be", and so on.
Of course, we have interesting questions in software too. "If you build the application using J2EE and Entity Beans, using that specific application server on that specific hardware, under your architectural decisions, how many transactions per second can we sustain (given a probability distribution of transaction types)?".
It's usually hard to answer those questions, unless you've done something very similar in the [near] past. Most people will try to answer by prototyping (I've done that quite a few times), meaning you quickly build something that may exhibit similar performance figures and try that out, or by ignoring the problem. They will build the system ignoring performance, usually adopting a specific technology and/or architecture out of trust, experience, faith :-) or whatever, and then add more hardware resources if they can't keep up with the load (assuming, of course, that it makes economic sense to add iron, that the architecture is indeed scalable, and so on).
Of course, if we had better design methods and tools, we could get some serious help. That would make software design much more useful, software architecture choices more visible and justifiable / justified, and so on (dunno what the agile guys would do at that point; move a little more toward design and a little further from code? But what about the need to know a little more about most users story to make the proper architectural decisions? Oh well... :-).
There are, of course, several attempts to come up with more quantitative methods in software. In the hard-real-time domain, schedulability has got huge attention over the years, and what is really missing now is an end-to-end (design - simulation - coding [not code generation] - profiling and back) tool for the masses. For the enterprise systems, IBM used to have proprietary data and tools, but that hardly qualifies as quantitative design.
A very interesting approach has been developed at University of Sidney (see "Design-Level Performance Prediction of Component-Based Architecture, IEEE Transactions on Software Engineering, November 2005). What the authors did was to define an abstract model of a J2EE container, develop an application-neutral benchmark that can be used to assess (once and forever) some parameters of a real container running on some real iron, and combine that application-neutral model with an application-dependent portion. The application-dependent portion is largely design-driven: you don't need to implement any code. The results, as published, are quite impressive. For a relatively simple application (barebone Online Stock Trading), implemented in J2EE using 2 different architectural patterns and on two different J2EE containers, the simulation was basically within 10% of the actual results. The real innovation, of course, is their ability to assess all the container-dependent parameters just once, with an application-neutral model.
As usual, they didn't give enough details to replicate everything in your lab :-), maybe with different technologies. In some sense, in a proper market that should fall on the container vendor (don't hold your breath :-), but when you have a home-grown architecture (I'm thinking of many reactive systems) it would be a huge boon to have a similar approach really working.
The authors use methods from queuing network theories, and reference a book that I've bought time ago but never had time to read ("Scaling for e-business" by Menasce' and Almeida). Despite the low-profile title, the book gives the subject a serious look, and uses a similar (queuing network) approach, although without the application-neutral / application-dependent separation. I guess I should set aside a little time and actually read it :-).
Comments:
Povere considerazioni sullo sviluppo del software

Quando si vuole realizzare un piccolo pollaio, spesso si pensa solo a procurare il materiale necessario e poi si realizza di getto l'opera senza pensare a calcoli per le strutture in cemento armato, né al rispetto di norme antisismiche o tutto quello che ogni geometra od ingegnere dovrebbe fare con cura. In verità al giorno d'oggi non si fa neppure un pollaio senza una meticolosa progettazione e successiva approvazione. Se si progetta un ponte sullo stretto oppure sul canale adiacente a casa, nessuno si sogna di saltare le fasi preparatorie con calcoli meticolosi. In realtà succede più spesso di quanto si pensi di rilevare a posteriori che la progettazione è stata carente. Lo studio preaparatorio, insomma, è ben proporzionato all'entità dell'opera che si intende realizzare.

Spesso col software questo non succede. Problemi semplici e banali sono spessissimo sopravvalutati ed altri grandi progetti sono carenti nella fase di analisi. Senza contare che ci sono questioni intrinsecamente difficili e non tutto è prevedibile a priori. Capita quindi di progettare pollai in cui per non essere limitativi si mette il pavimento in monocottura, perché non si sa mai cosa un domani potranno contenere, oppure tendine in raso alle finestre oppure abbeveratoi in acciaio e smalti pregiati. Come è facile lasciarsi prendere la mano in lavori di poco conto, altrettanto facilmente si cade nel banale su cose importanti e si finisce per adottare in ambiente enterprise la soluzione confezionata dal ragazzino o dal neolaureato che adatta il progettino scritto per la tesi di laurea. Eh si, perché per rendere professionale la soluzione, invece del vecchio PC di casa è sufficiente far girare il tutto sul server azienzale multi-processore con giga-RAM.

Carlo, tu che giri spesso per aziende, quante volte hai visto cose di questo tipo? Se non fosse così avresti già smesso di lavorare :-((
 
Romano: nota la subdola :-) relazione tra questo e la storia delle profezie autorealizzanti.

Arrivando al succo della domanda, io direi che nei miei ormai innumerevoli :-)) contatti con aziende di ogni tipo, vedo intanto un partizionamento del software in 3 gruppi (per i primi due, uso la terminologia di Grady Booch):

1) Accidental Architecture: il software ha una sua struttura, non e' semplicemente una accozzaglia di funzioni, strutture, classi. Tuttavia non ha una architettura intenzionale, pianificata. Ha quella che alcuni definirebbero una architettura emergente [dallo sviluppo, refactoring, ecc].

2) Intentional Architecture: il software ha una struttura che, in larga misura (tanto piu' larga quanto piu' astratto e' il punto di osservazione) e' stata progettata sin dall'inizio, con alcuni riaggiustamenti in corsa che non hanno stravolto la struttura portante.

3) [Booch non parla di questo, forse perche', nei suoi ultimi lavori si focalizza su sistemi che hanno avuto successo :-))] No architecture. Il software semplicemente non ha struttura. E' un ammasso di roba che, alla fine, piu' o meno, funziona.

Quanta sovraingegnerizzazione vedo nella pratica? Relativamente poca, tipicamente piu' spesso presente nel tipo (2). Ma sinceramente, se non guardo a sistemi troppo vecchi (mancanza di cultura generale su cosa volesse dire OOD) o scritti da novellini, anche bravi neolaureati ma ancora con l'impronta accademica, ne vedo decisamente poca, al di la' dello spauracchio agilista (che infatti, piu' volte, a me pare il classico strawman :-)

Quanta sottoingegnerizzazione vedo? Tanta :-). Ovviamente i (3) sono tutti sottoingegnerizzati, e c'e' un sacco di (3) in giro, ovunque persone che di software, in realta', non sanno nulla, ma sanno [piu' o meno] programmare, vengono messe per qualche ragione a scrivere porzioni di software non banali. Anche negli (1) vedo tante parti sottoingegnerizzate. Tipicamente trovo architetture banali con controllori termonucleari globali :-) che coordinano una marea di classi stupide. Ma anche grossissime opportunita' di miglioramento su accoppiamento, coesione, estendibilita', riusabilita', ecc ecc, che sarebbero state a costo zero se gestite in tempo.

Per quanto riguarda l'ultima parte (restare senza lavoro :-), devo dire che non credo proprio :-)). Anche se avessimo metodi piu' quantitativi, piu' sistematici, ecc, il software e' un campo molto ampio, molto dinamico, in cui le conoscenze ed il talento individuale non vengono intaccate (anzi, a mio avviso vengono amplificate) dall'esistenza di un corpus di conoscenze piu' consolidato. In effetti, con i miei clienti "migliori" cio' che avviene e' che iniziamo a lavorare su certi aspetti in cui ci sono spazi di miglioramento immediati (tipicamente proprio il design), e quando diventano bravi su quello ci spostiamo a migliorare altre cose, e poi altre ancora, ecc ecc...
 
Salve Dott. Pescio,
sono rimassto incuriosito dal suo blog a dalle interessanti tematiche trattate...
Relativamente al suo ultimo post, penso che sia necessario inserire il discorso che, nel recente mercato informatico, il Design e l'Analisi sono sempre più divenuti prodotti. Questo ruolo porta un pò di caos ed a volte ad un impoverimento dei contenuti/risultati(sottoingegnerizzazione)... Pensiamo ad un povero neolaureato ed a quanti trend deve seguire! Ma chi sa definire cos'è un Business Object? Relativamente al perdere o non il lavoro mi sembra che l'Informatica Commerciale, in quanto espressione di una "logica-creatività-lucrosa" umana, premia l'esperienza e la genialità ma, fa soffrire e non e' meritocratica!
Un ultima osservazione: ma come mai ha sempre una dialettica così tagliente? Sinceramente, faccine o meno, proprio da una persona della sua caratura mi aspetterei una capacità di controllo ed un'abilità di comprensione verso il prossimo più immediata... Ho visto male? Se così fosse me ne scuso ed ancora complimenti per la sua efficace carriera
 
La prima parte (design/analisi come prodotti, e questo come causa della sottoingegnerizzazione) temo proprio di non averla capita :-(.

Sui trend ed il povero neolaureato, sarebbe un bel discorso, interessante ma anche tanto lungo... il neolaureato a mio avviso farebbe molto meglio a crearsi basi sempre piu' solide [teoriche e pratiche] ed a seguire pochi trend, diciamo uno o due che gli piacciono e che abbiano anche una chance di fargli trovare un lavoro che gli piaccia. Ovviamente sarebbe meglio se seguisse un trend con un futuro :-), e qui diventa davvero molto complicato, specie per un neolaureato.

A riprova della dialettica tagliente :-)), come fa una disciplina che "premia l'esperienza e la genialità" a non essere meritocratica? (Ovviamente, i meriti lavorativi di una persona non si limitano alle sue conoscenze / capacita' tecniche, in nessuna disciplina).
La mia esperienza e' che la meritocrazia in informatica e' molto forte nelle aziende che hanno come core business l'informatica, e decade rapidamente nelle altre, sia in un verso (con degli incapaci ritenuti dei genialoidi) che nell'altro (con degli ottimi tecnici ritenuti risorse sostituibili a costo zero).

Giusto per dire due parole sulla dialettica: ci sono sicuramente molte situazioni, lavorative ed umane, dove e' necessario procedere con grande cautela, per indirezioni, con tatto e strategia. Posso anche dire che mi capitano con una certa frequenza in ambito lavorativo: le aziende medio-grandi sono spesso ambienti "difficili" da un punto di vista sociale.
Questo blog, per fortuna :-), e' invece uno spazio dove voglio privilegiare una forma di comunicazione diretta ed immediata (un mio vecchio post si intitolava giustappunto "blogging as destructuring"). Credo che la maggior parte delle persone che arrivano a leggere / scrivere qui sia ben conscia della trasmutazione :-) che alcune parole assumono nella forma sintetica della comunicazione elettronica. Le faccine servono appunto a ricordare che in real life ci faremmo su una risata e nessuno se la prenderebbe, ed andrebbero prese come tali.
Cio' a cui invece non voglio dare posto sono gli interventi (come avvenuto di recente) che nascondono dietro una forma falsamente cortese insulti piu' o meno velati. A questi credo di aver risposto, a dire il vero, in modo non sufficientemente tagliente :-)
(ok, ok, confesso, sono cattivissimo :-)))).
 
Visto che sarò nel giro di un anno un neolaureato :-))), qualche suggerimento sul trend da seguire sarebbe utile. Per le solide basi ci stiamo attrezzando, ma per il trend? in giro si sente parlare di Java e .NET (molto del primo e poco del secondo dalle mie parte) e delle tecnologie agili. Adesso premettendo che Java mi piace poco, .NET lo sto imparando, e le metodologie agili mi piacciono così così (anche se è più una cosa di intuito che altro), cosa consigli?
 
per Fulvio:
rileggi immediatamente "Self-fulfilling expectations"!!
;))
credo che il trend dei prossimi sara' orientato verso 4 grandi poli tecnologici: Java, .NET, ABAP (SAP) e le tecnologie Embedded.
Impara tutto, ma soprattutto, impara ad imparare!
In bocca al lupo per la tua laurea (e facci sapere il titolo della tesi!)

Michel
 
Non vorrei portare la discussione troppo fuori dal tema originale, ma trovo interessante la questione dei trend, di cosa studiare, eccetera. Pongo alcune domande alle quali non so dare risposta completa.

1) Mediamente il software e' fatto malino, sia vecchio che nuovo, stando all'esperienza di Carlo Pescio. Quale impatto ha avuto, se l'ha avuto, il trend tecnologico del momento?

2) Il programmatore deve sapere programmare indipendentemente dal linguaggio e piattaforma (sto generalizzando all'ennesima potenza). Si dovrebbe supporre quindi che il programmatore, messo davanti a Java o a .NET o C++, sia in grado di lavorare come si deve. Pero' colloquialmente (anche nel vero senso della parola :-) si dice "me ne intendo di Java" come se si volesse dare una connotazione molto forte al tipo di preparazione. Forse si vuole intendere "mi intendo dei problemi tipicamente risolti con Java (e quindi di Java usato in un certo modo)"?

3) Corsi e ricorsi sono pane quotidiano in informatica. I problemi (con relative soluzioni) c'erano quasi tutti gia' tanti anni fa. Oggi abbiamo versioni ammodernate dei "soliti" problemi, almeno cosi' mi pare, e le tecnologie del momento sono lo strumento con cui oggi li risolviamo. Quindi, quanto e' *realmente* importante avere esperienza pratica con le tecnologie del momento?

4) Dai che e' l'ultima... :-) Spesso sento dire frasi tipo "quella cosa falla con .NET che ci metti un attimo". E' una frase che non mi piace, perche' mi suggerisce un approccio in cui la tecnologia "nuova" e' tutto: e' la domanda, e' la risposta, e' il confine che non puoi superare, e' il modo di lavorare, e' una mentalita'. Credo che dovrebbe essere solo uno strumento. Nostro compito e' capire l'essenza dei diversi strumenti, per sceglierli senza subirli. Per far cio' serve essenzialmente cultura.
 
Fulvio, ma non avevo detto che era difficile? :-)) Per una visione realistica delle previsioni, vedere qui: http://en.wikiquote.org/wiki/Forecasting
(letta la prima, come si fa a proseguire? :-))

Metto momentaneamente una risposta per te in stand-by (anche perche' magari qualcun altro prova a rispondere al posto mio :-)) e provo a dire qualcosa al Citrullo, che fa nuovamente domande difficilissime :-). Cosi' difficili che per ora rispondo solo alla #2, per le altre ci provo nei prossimi giorni.

Un buon programmatore, hai ragione, sa prima di tutto programmare. Detto in modo ancora piu' estremo ed ancora piu' generalizzante, sa programmare non solo indipendentemente dalla piattaforma e dal linguaggio ma anche dal paradigma. Tuttavia questo non significa che un buon programmatore possa, in breve tempo (o in tempo zero) essere realmente a suo agio, rapido, corretto e produttivo con un nuovo linguaggio o piattaforma. Vediamo qualche esempio:

- il linguaggio puo' essere ampio e complesso da imparare a fondo (C++) o distante dai modelli "noti" al programmatore (che so, prime esperienze in Prolog per chi viene dal C :-).

- accanto ad un linguaggio vi sono numerosi idiomi che nascono con l'esperienza in quel linguaggio. Pensa al RAII in C++, piuttosto che all'uso furbo delle inner class in Java, piuttosto che all'uso mirato degli attributi in .NET.

- un linguaggio si porta dietro sempre anche una libreria, piu' o meno corposa, standard o homegrown. Qui e' dove vedo la parete piu' verticale per tanti programmatori (e li capisco bene). Dopo un tot di anni passati ad apprendere bene una libreria ampia, tutta questa voglia di passare ad un'altra e' difficile trovarla, e senza dimestichezza con la libreria, e' difficile essere rapidi e produttivi.

- la libreria a volte sfocia nella piattaforma. Avere esperienza con MFC non aiutera' molto a scrivere al volo applicazioni J2EE (e neppure a comprenderne "istintivamente" i principali pattern), ne' ovviamente e' vero il viceversa.

- a fianco a questo dobbiamo mettere anche i tool. Conoscere bene un linguaggio puo' voler dire conoscere bene anche cosa puo' darci un compilatore (importante ad es. per i sistemi embedded), piuttosto che saper usare bene un debugger sofisticato, o tool al contorno per controllare i memory leak, ecc ecc.

E' quindi evidente che chi dice "mi intendo di Java" probabilmente vuol dire (ammesso che se ne intenda davvero :-) che ha capito il paradigma ad oggetti, conosce la sintassi e le peculiarita' del linguaggio, conosce gli idiomi tipici di Java come linguaggio, conosce la sua libreria, conosce probabilmente alcuni pattern tipici, sia che lavori in J2SE che J2EE, e magari conosce le limitazioni ed il modo in cui conviverci se parliamo di J2ME. Conoscera' anche un buon ambiente di sviluppo, ecc ecc.

Ovviamente, se non e' un buon programmatore, nulla di tutto questo ha senso. E purtroppo la verita' e' che ci sono moltissimi coder improvvisati, che imparano in modo superficiale il linguaggio (confondendo paradigma, linguaggio, idiomi, persino pattern), e che lavorano per schemi rigidi. Ma rimanendo con il focus sul buon programmatore, e' ovvio che conoscere a fondo "un linguaggio" vuol dire molto di piu' che conoscerne bene la sintassi e la semantica, almeno se vogliamo realmente usarlo. Cio' che posso dire e' che piu' bravi si diventa, piu' e' facile imparare altre cose, ma solo se manteniamo la mente aperta, altrimenti le conoscenze pregresse diventano un peso anziche' un vantaggio...

A questo punto mi pare che con un sforzo minimo forse riesco a rispondere anche alla #3 :-). L'esperienza pratica con le tecnologie del momento ovviamente aiuta ad essere piu' rapidamente produttivi ed a scrivere software realmente allineato con il modello di sviluppo ideale di .NET piuttosto che di Java. Cio' che va accuratamente evitato e' invece di avere solo esperienza pratica con le sole tecnologie del momento...

La #4 e' controversa e ne parliamo domani o dopo :-). Il lato divertente e' che anni fa avevo iniziato a scrivere un articoletto su temi analoghi (mi pare di averlo tentativamente intitolato Wisdom & Pride) ma non l'ho mai terminato :-).

La #1 e' complicatissima, sarebbe meglio rispondere prima a Fulvio :-). Ma giusto per non andare a dormire senza una chance di fare arrabbiare qualcuno :-))) diro' una cosa su Java come trend da seguire. Cercatevi con google "java is the new cobol", con tanto di virgolette. Poi pensate che e' una posizione decisamente invidiabile per un linguaggio, but oh, so dull :-)). <-- notare le faccine :-))
 
Carlo, sei un uomo coraggioso! Dopo esser stato velatamente insultato dagli agilisti ora hai il coraggio di scrivere "java is the new cobol"... a questo punto penso che oltre alle tue eccellenti conoscenze informatiche stai prendendo anche lezioni di kung fu e stai cercando dei candidati per metterle in pratica :-)

Per rispondere seriamente, anche a Fulvio, comunque il Cobol ha dato il pane a tanti informatici; e in questo momento lo stesso vale anche per Java (soprattutto in Italia, all'estero la situazione è maggiormente bilanciata). Un neolaureto che vuole capire un trend da seguire (che gli assicuri anche del cibo :-)) può ovviamente iniziare a fare una statistica dei profili maggiormente ricercati dai vari recruiter o su siti specializzati in ricerca di personale. Poi, come dice Carlo, deve crearsi delle solide basi. Ci sono delle conoscenze che sono trasversali ai trend e che sono indispensabili per evitare di essere solo un coder (scarso magari...). Ma su questo punto non mi dilungo visto che in parte è già stato affrontato nei post precedenti. Aggiungerei solo una qualità indispensabile per qualunque persona/lavoratore: la voglia e la capacità di continuare ad imparare (sempre!).

Mi permetto anch'io una domanda "cattiva" a Carlo... quante aziende informatiche conosci che hanno realmente come core business l'informatica? Mi basta anche una percentuale sul totale...
 
La domanda di Michele e' facile (finalmente :-)))) e quindi rispondo al volo.

Le aziende "informatiche" le distinguo spesso in due categorie: quelle che sanno di avere come core business l'informatica , e quelle che ancora non l'hanno capito.

Se penso a quante sono ad avere come core business l'informatica consapevolmente, allora non tantissime. Parlando di numeri, direi che comunque il 50% del mio fatturato deriva da quel tipo di aziende.

Poi esiste una casistica molto ampia di aziende che erano nate in altro modo, ma che di fatto oggi hanno come core business l'informatica. Nel senso che tutto il resto potrebbero recuperarlo altrove (o gia' lo fanno), oppure e' stabile da secoli, e l'unica vera innovazione arriva dal software, o solo grazie a software custom possono intraprendere i loro nuovi modelli di business. E come dice Tom Peters, un'azienda e' fatta solo di Marketing ed Innovazione (anche qui, qualcuno se la prendera' ;-).
Ad esempio, molte aziende "di automazione" sono in realta' delle software house senza saperlo (purtroppo, mi viene da dire in molti casi).
Le banche e le assicurazioni che NON hanno creato una loro software house [core business = informatica] si trovano in una situazione complessa, perche' lo sviluppo di software custom e' sempre piu' vicino al loro core business (nel senso che lo sostiene ed in certi casi lo permette). Oggi, posso fare una banca o una assicurazione senza sportelli, ma non senza informatica. Questo non le qualifica come aziende con core business informatico, ma sotto il coperchio hanno una azienda con core business informatico...
Qui direi che finisce piu' o meno l'altro 50% del mio fatturato.

Ovviamente, non ho idea di quanto la mia distribuzione di fatturato sia statisticamente significativa :-). Michele, la tua com'e'? :-)))
 
Dopo esser stato velatamente insultato dagli agilisti

Michele non generalizziamo :-)
 
Parto dall'ultimo commento. No, Marco non volevo generalizzare. Ho solo fatto una battuta riferendomi al precedete post dove i toni sono stati meno amichevoli del solito (e infatti ho evitato di parteciparvi :-)). La battuta era riferita al fatto che se Carlo volesse iniziare una "guerra santa", in questo modo ha provocato una fazione nutrita e coriacea (e diciamolo, anche con ottime armi). Ovviamente non volevo offendere nessuno, e soprattutto te (non sono un agilista, ma fra le poche cose "agili" italiane che ho letto tu sei in testa :-)).

Per Carlo: al momento sono dipendente di una software house (che sa di avere come core business l'informatica) e sono allocato da ormai 3 anni su un progetto di un istituto bancario. La distribuzione del mio fatturato è facilmente desumibile :-)

La mia domanda era tendenziosa... mi riferivo a tutte quelle società che si dipingono come società informatiche ma che in pratica altro non fanno che body rental, andando ad assomigliare assai a delle agenzie interinali... direi di aggiungere quindi un'ulteriore categoria: quello che dicono di avere come core business l'informatica.

Finisco sulle società che come tu dici "sotto il coperchio hanno una azienda con core business informatico". Fra di loro purtroppo ricadono tante società che lavorano con tantissimo outsourcing, alcune fino al punto dal non avere neanche la knowledge base del loro software... e il pensiero che il core business di un'azienda è basato su qualcosa del quale sa poco o nulla mi mette sempre i brividi...
 
Come promesso :-) provo a rispondere almeno alla #4 del Citrullo.
Da un lato sono profondamente d'accordo con quel che dici. In informatica l'idea "nuovo = bello ergo vecchio = brutto" e' molto radicata, in parte perche' molti non hanno neppure capito bene il vecchio (ne riparlero' provando a rispondere alla #1), e quindi tanto vale buttarsi (lo dico in senso dispregiativo :-)) sul nuovo.
La conseguenza netta di tutto questo e' una mancanza totale di "saggezza" (da cui parte del titolo dell'articolo mai finito), e visto che ho imparato il termine da poco :-)), una complessiva metacognitive miscalibration che rende difficile imparare realmente, e come dici tu, capire l'essenza dei diversi strumenti senza subirli.
Chi manca di questa saggezza, si infila spesso in posizioni fideistico-tribali, in cui sfoggia orgogliosamente (da cui l'altra parte del titolo) la propria appartenenza ad un gruppo.
Detto tutto questo, esistono moltissime situazioni in cui le persone si fanno del male da sole :-), usando strumenti totalmente inadeguati.
Non troppo tempo fa esaminavo rapidamente con alcune persone i requisiti di una applicazione web piuttosto semplice. Con un minimo di fatica abbiamo fatto si' che qualcosa venisse gratis, ovvero che alcune pagine non fossero altro che una vesione "a filtri bloccati" di altre pagine. Li ho anche invitati a rinegoziare un requisito, perche' a mio avviso potevamo avere il 90% o piu' del valore con il 10% dell'investimento, cambiando un po' la richiesta (sul fatto che gli analisti devono inventare i requisiti ci tornero' in un altro momento). Ma alla fine del gioco, restava un tot di lavoro. Lavoro che il gruppo portera' avanti in PHP, perche' quello e' l'ambiente con cui hanno piu' confidenza, mentre con Java lato server sono relativamente all'inizio.
La cosa triste e' che realmente, in ASP.NET quella applicazione l'avrebbero scritta in un quarto del tempo se non meno (sorry per i PHP-fan :-).
Ovviamente bisogna conoscere un po' lo strumento, ma qui siamo alle solite: non bisogna fossilizzarsi su cio' che si conosce, non bisogna pensare che cio' che funziona bene su piccola scala funzioni altrettanto bene su scala piu' grande, ecc ecc.
Tanto per citare un tema vicino a voi, a me ad esempio dispiace che sull'onda lunga del COM si stia ignorando .NET, perche' ci sono molti aspetti di GUI che si risolverebbero con maggiore efficienza (di sviluppo) in .NET, semplicemente perche' la libreria e' fatta estremamente meglio. Anche problematiche di capture & playback sarebbero interessanti da investigare in ottica dichiarativo / introspettiva, eccetera. Queste cose non si fanno per tante ragioni (alcune sensate, alcune sbagliate), ma e' innegabile che alcune tecnologie (nuove o vecchie che siano) hanno un migliore allineamento con alcune specifiche esigenze, e che scegliere lo strumento adatto puo' semplificare la vita. Al solito, a fianco a questo c'e' il tempo di apprendimento della nuova tecnologia, e qui finiamo nella #2 :-). A fianco, ci sarebbe un discorso ancora piu' complicato, ovvero il fatto che un'azienda non puo' frammentare le sue competenze in modo eccessivo, per tante ragioni. Ma almeno su questo, per ora, glisso :-).
 
Michele: come forse sai non sono un grande fan del body rental. Lo capisco come business opportunity (per chi lo fornisce) e capisco anche come, in un mercato del lavoro rigido, fornisca una flessibilita' che in situazioni specifiche e' fondamentale (ed in altre e' ovviamente abusata). Siccome qui finiamo nella politica :-), che non e' uno dei temi del blog, non vado oltre :-).

Per chi, a suon di outsourcing, perde il controllo o persino la percezione di cosa sta facendo, temo che in definitiva sara' il mercato a spiegare che stava sbagliando approccio :-). Viceversa, un outsourcing mirato di parti marginali o collaterali rispetto al core business e' a mio avviso una buona pratica in molte situazioni specifiche. Ma qui bisogna entrare nei dettagli della strategia aziendale, dei prodotti realizzati, del mercato, della crescita interna e del mercato stesso, ecc ecc...
 
Provo a dare anche una risposta alla #1 del Citrullo. Nel frattempo perche' qualcuno non da' qualche buon consiglio a Fulvio?

Proverei a distinguere i trend puramente tecnologici da quelli metodologici. Java, .NET, Phyton et similia appartengono al reame dei tecnologici. Anche le applicazioni web, in larga misura, sono solo questioni tecnologiche. L'uso pervasivo di XML e' un trend tecnologico. I web services sono un trend tecnologico.
Tra i trend metodologici ci metterei OOP, OOD, Pattern-Oriented Architecture, l'uso di dati semistrutturati (controaltare metodologico di XML), Service Oriented Architecture (che e' il controaltare metodologico dei web service), AOP, ecc.
Aggeggi tipo UML e' difficile classificarli, nel senso che fondono sia aspetti metodologici (intendo Visual Modeling, non certo RUP), sia aspetti tecnologici (l'UML in se' come semplice linguaggio, i tool di contorno). I metodi agili, cosi' come tutti gli altri :-), sono ovviamente sul versante metodologico.

A questo punto posso dire la cosa grossa :-) per prima, cosi' chi si vuole arrabbiare si arrabbia e via (ma non credo saranno molti). In generale, l'impatto delle innovazioni (lascio un attimo da parte il termine "trend") e' sempre stato piuttosto contenuto in informatica, per una serie di motivi. Quello predominante, a mio avviso, e' stata l'enfasi enorme sull'aspetto tecnologico, separato da quello metodologico. Tutti si "buttano" sulla tecnologia (che alla fine e' sempre molto facile anche per lo smanettone di turno), pochi capiscono a fondo gli aspetti metodologici che vi stanno dietro. Il fallimento e' dietro l'angolo.
Le altre ragioni si sommano. Il desiderio di buttare via tutto, di cui si e' gia' parlato. La deliberata scelta di alcuni di reinventare e rinominare concetti gia' esistenti. La frammentazione tribale, che si pasce :-) anche di questa separazione linguistica.

Conseguenza netta: il trend tecnologico del momento in genere non ha impatti sensibili nella massa. Ha pero' sicuramente impatti piu' che sensibili dove riesce ad attecchire insieme agli aspetti metodologici che lo accompagnano e supportano. Il fatto che tanto software continui ad essere fatto male e' una riprova che l'eccessiva enfasi sulla tecnologia non porta a prodotti migliori. Ma ci sono tantissime aziende, o gruppi all'interno di aziende piu' grandi, che in media lavorano molto bene. Ci sono sempre grandi spazi di miglioramento, basta riuscire a colmarne un po' ogni giorno ed e' fatta :-). In quest'ottica, provo un po' di fastidio ogni volta che arriva il santone di turno, che vuole disfare tutto il grande lavoro fatto nel corso degli anni, predicando approcci intransigenti e totalizzanti...

Notate che ho accuratamente lasciato fuori le motivazioni spesso portate da tanti programmatori (il mercato, le pressioni, ecc ecc). Da un lato perche' c'entrano relativamente poco con la domanda originale, dall'altro perche' semplicemente non sono d'accordo :-). Il mercato, le pressioni, ecc ecc, sono parte del gioco e vanno gestite. Se c'e' davvero un problema, e' la difficolta' da parte di tanti tecnici di collaborare con il resto dell'azienda su questi temi. Dove collaborare vuol dire, prima di tutto, dimostrare di capire il problema di business, farsi rispettare per la propria comprensione del problema, per il contributo che si da' alla soluzione e per la capacita' di comunicare con le altre figure aziendali senza rinchiudersi nel circolo dei nerd :-). Di questo ho gia' parlato in altri post (come
The Nerd as a Commodity
e Nerds, Commodities and Business skills (again)) e quindi evito di ripetermi...
 
innanzi tutto grazie a michel per la prima risposta.

Per Carlo: ancora oggi mi chiedo dove trovi il tempo per imparare tutto quello che sai (lo so, è una domanda che ti ho già fatto, ma ogni volta rimango stupito, e mi chiedo se non è meglio aprire un bar su una spiaggia jamaicana! ) Cmq sia, mi mancano ancora 6 esami sono giovane e imparo in fretta (certo non vorrei dover imparare qualcosa che tra 1 anno non mi servirà a niente ed averla imparata perchè poteva fare curriculum per un'eventuale assunzione! :-)))
 
Fulvio, sai cosa penso mi abbia giovato di più per la mia attuale attività di programmatore?

Lo studio del latino e del greco.
 
Provo a rispondere a Fulvio, in realta' un po' arbitrariamente cambio la domanda da "quale trend seguire?" a "cosa e' utile sapere / studiare / seguire per un laureando o quasi?".

Partirei da alcune cose che a mio avviso un laureato (non ricordo se studi Informatica o Ingegneria Informatica, ma fa lo stesso) "moderno" non puo' non sapere. E' ovviamente un elenco parziale e molto orientato ad un inserimento nel mondo del lavoro. E' ovvio che da un laureato ci si aspetta sempre anche un tot di altre cose (forma mentis, dimestichezza con la logica / matematica, capacita' di apprendere rapidamente nuovi concetti, ecc ecc).
Rimanendo pero' sul pratico / lavorativo, un buon neolaureato deve conoscere bene la programmazione come attivita' e schema di pensiero (computational thinking). Deve conoscere la programmazione ad oggetti come paradigma, deve conoscere bene almeno uno tra C++, Java, C# come linguaggio (al di la' della libreria). Idealmente, mi aspetto C++ ed uno degli altri due, viste le differenze significative negli idiomi. Deve conoscere bene la teoria delle basi di dati (normalizzazione e compagni) ed avere una ragionevole pratica di SQL. Deve conoscere le problematiche tipiche delle applicazioni web, ma ormai anche dei web services / SOA. Deve saper progettare un sistema, quindi conoscere i principi di design e come metterli insieme; meglio se sa farlo con un po' di UML. Sarei contento se conoscesse un po' di pattern. Dovrebbe anche saper analizzare un problema vago e mal formulato, ma questo e' probabilmente l'aspetto su cui molti saranno carenti e tutti siamo abbastanza propensi ad accettarlo. Ho sicuramente lasciato fuori qualcosa, aiutatemi pure :-) a completare la lista.

Detto questo, cosa ha senso che studi / approfondisca ulteriormente? Premetto che rimango sul tema "inserimento nel mondo del lavoro". Se uno vuol fare il dottorato e poi il ricercatore, le cose cambiano. A mio avviso una conoscenza di Java e .NET e' ormai quasi una questione di igiene :-), ovvero se manca e' un problema, se c'e' non e' che si spicchi in modo particolare. Quindi deve esserci, e per quanto riguarda Java io privilegerei J2EE; java sui client non esiste, J2ME e' carino ma o hai una passione sfrenata :-) per queste cose (e allora ok) oppure e' una nicchia cosi' piccola che non so quanto abbia senso investirci molto (ma smanettarci un pochino magari si). .NET e', in questo momento storico, molto piu' dinamico. Quindi avere una buona conoscenza della piattaforma e delle sue diramazioni (Windows Forms, Web Forms, ma anche tutte le cose "nuove" tipo Indigo, Windows Workflow Foundation, ecc ecc) puo' essere interessante. Questo se si vuole lavorare nel filone "mainstream" dello sviluppo. Nota che qui non sto piu' parlando di linguaggi, ma di conoscenza della piattaforma, librerie, idiomi, pattern, ecc.
Se ti piace ti piu' la programmazione embedded, che come gia' diceva Michel sara' sicuramente uno dei settori di maggior sviluppo, ti consiglierei di andare un po' oltre i soliti PIC (dove gli smanettoni abbondano) e di cercare di approfondire la programmazione su sistemi operativi real-time (nell'ordine di quelli che ti faranno ritenere "prezioso" (ad oggi) VxWorks, QNX, WinCE, versioni embedded di linux (direi a pari merito con CE). Se poi ti studi anche qui un po' di pattern specifici fai una cosa buona e giusta. Idealmente, sarebbe bello riuscire a smanettare un po' anche con VHDL ed avere idea di cosa si puo' fare con una FPGA. Anche saper scrivere un kernel driver su (es.) Windows XP non sarebbe malissimo, visto che c'e' sempre piu' la tentazione di usare Windows dappertutto. Non e' magia nera, ed un bravo ragazzo ce la fa sicuramente con un libro ed un po' di buona volonta'.

Io consiglierei sempre al nostro bravo laureando di seguire / approfondire, oltre ai temi piu' tecnologici come quelli sopra, qualcosa di piu' metodologico (vedi risposte precedenti). Ad esempio, in questo periodo troverei molto interessante approfondire l'Aspect Oriented Programming e tutti i vari lavori che ruotano intorno al tema "Software Engineering Economics" (anche se, da un neo-neo laureato, pochi vorranno sentirsi dare consigli sul tema :->, ma devi solo resistere un po' :-)). Personalmente, al di la' degli stimoli personali, posso dire che infatuarsi dell'ennesimo linguaggio di nicchia difficilmente portera' ad una accoglienza a braccia aperte nelle aziende (anzi :-)), ma non e' detto che sia sempre vero.

Tieni sempre presenti, pero', le tue vere passioni, magari mediate da un po' di sano realismo: se il desiderio della tua vita e' lavorare ai videogame, studiare J2EE non ti portera' necessariamente nel verso giusto, J2ME o DirectX magari si' :-).

L'ultimo consiglio, anche perche' mi rendo conto di aver detto piu' o meno tutte cose ovvie (sorry :-). Quello che mi aspetto di piu' dal famoso neolaureato e' che abbia metabolizzato cosa vuol dire Ingegneria del Software, che non si sieda semplicemente davanti al PC ed inizi a smanettare, e che sia continuamente disposto (anzi propenso) a rivalutare cio' che sta apprendendo, cio' che gli altri propongono, ecc ecc, in una luce critica ma costruttiva. E che sappia pero' anche sedersi davanti al PC a smanettare, perche' di teoriconi self-proclaimed-guru I'm-a-legend-in-my-living-room che poi non sanno disegnare un cerchio :-))) ce ne sono fin troppi :-)

Ok, chiunque abbia consigli migliori si faccia avanti, non sono molto soddisfatto di quanto sopra :-)
 
Grazie per le molte risposte.
Carlo, non e' un po' lunga la lista di cose da sapere? Il povero neolaureato ci mettera' sei mesi solo per procurarsi il materiale da studiare! :-)
A parte la lunghezza della lista, e' interessante cio' che hai scritto, anche se non mi aspettavo spunti molto diverse in verita'. Pero' aggiungerei qualcos'altro, magari un tratto d'unione tra gli argomenti molto specifici che hai indicato, e quelli astratti di Romano Scuri, tipo il greco e il latino. Che anche secondo me sono decisivi, senza dover passare alla retorica.
Restando nell'ambito informatico, c'e' un equivalente di greco e latino, che possa aprire la mente e appesantire un bel po' il bagaglio culturale generale? Vi racconto i cavoli miei, vedete voi se tornano utili.

All'universita', corso di Informatica, Linux era "il" sistema operativo. La motivazione era che se vuoi capire un sistema operativo, allora come minimo devi capire Unix. Ora posso dire che questa scelta e' stata fruttuosa, vedo infatti che la maggior parte degli addetti ai lavori non ha sviluppato il minimo senso critico nei confronti del sistema operativo. Ma hanno perso anche l'opportunita' di vedere le cose da un punto di vista diverso: la "mentalita' Unix" e' un tesoro a cui attingere a piene mani, e ha contribuito in modo significativo sia nella mia formazione che, indirettamente, nel lavoro.
Nel triennio scelsi l'indirizzo computazionale di Informatica, eravamo in sette perche' quasi tutti sceglievano reti o altro. Molte cose che studiai forse non le applichero' mai (nonostante il mio attuale lavoro corrisponda perfettamente al corso di studi... fortuna, eh? :-). Eppure mi rendo conto di avere conoscenze che mi danno un punto di vista diverso, e che tornano pure utili quando meno te lo aspetti.

Con questo non voglio dire che va sempre studiata la roba "alternativa", perche' prima di tutto bisogna pensare a cio' che va per la maggiore. Pero' esistono argomenti chiave che danno una marcia in piu', e che sorprendentemente in pochi approfondiscono. Sicuramente ci metto dentro Unix. Sul computazionale non so indicare nulla di specifico, credo che vada bene un qualsiasi argomento che solleciti la capacita' di trasformare una soluzione matematica in algoritmo, e poi in programma.

Mah, sono stato un po' fumoso. Mi interessa principalmente confermare il pensiero iniziale, cioe' che esistono degli argomenti specifici "must" che vanno capiti e apprezzati per quello che sono, grazie ai quali si ha veramente una marcia in piu'.
 
Carlo da profondo conoscitore del mercato IT dà una serie di consigli del tutto condivisibili.

L'elenco però, come dice anche Citrullo, è particolarmente lungo (considerando anche che Fulvio nell'anno a venire ha davanti a sé anche 6 esami e una tesi; in bocca al lupo anticipatamente :-)).

Aggiungerei quindi un consiglio per Fulvio. Il mercato richiede (anche grazie alla flessibilità) competenze sempre più specifiche. Attento allora alla utopica tentazione di divenire un "tuttologo", e cerca nel novero delle doverose conoscenze elencate di eccellere in alcune (scelte per passione, statistiche o quanto altro ritieni opportuno).

In tema di fatti propri, quando fui assunto dalla mia attuale società lo fui soprattutto per la mia conoscenza del C++. E per questo non finirò mai di ringraziare Carlo e i suoi scritti :-)
 
Sono sbagliati i link ai precedenti post di Carlo Pescio. Nell'indirizzo va sostituito "www.blogger.com" con "www.eptacom.com"
 
Ciao Carlo, l'articolo The Nerd as a Commodity è sempre appeso all'armadio nella mia camera...
 
Poche note brevi:
la mia lista e' lunga ma, nella mia visione ottimistica della vita, vorrei tanto che il neolaureato alcune di quelle cose le avesse studiate come parte del suo piano di studi! Poi mi rendo conto che in molte universita' nessuno insegna il design. Il lato divertente e' che invece in molte universita' si sono buttati su XP alla grande, per ragioni a mio avviso del tutto correlate :-).
Pero' se in un corso moderno non insegnano nulla di tutto quello che ho elencato, siamo messi male :-).
Detto questo, ha sicuramente ragione Michele quando dice: oltre a sapere, ad un livello che io ho definito "igienico" (ho rubato il termine a De Marco, o forse a Yourdon, non ricordo bene), e' interessante conoscere qualcosa molto piu' a fondo. Qui e' dove si inserisce quell'elemento di passione cui accennavo.
Su qualcosa che apra la mente, senza finire nel greco o nel sanscrito :-), magari ci torno anche in seguito. Giusto per dare qualche idea, a mio avviso qualcosa di estremamente utile per distinguere bene teoria e praticoneria e' la teoria della calcolabilita'. Ad esempio, sarebbe carino che qualcuno trovasse una bella funzione F per cui si puo' dimostrare che F e' computabile e Test( F ) non e' computabile / semicomputabile (dove Test( F ) e' un predicato che dice se F e' implementata "bene"). A naso, ispirandosi al solito halting problem, se non al classico stratagemma di Goedel, qualcosa si fa senza troppa fatica :-). Questo aiuterebbe a derimere alla radice alcuni dibattiti sul ruolo dei test automatici :-). In generale, spendere un po' di tempo su queste cose, cosi' come su semantica denotazionale e compagni per quanto riguarda i linguaggi, apre ed affina abbastanza la mente.
 
Carlo concordo con te sul discorso universita' ma dato che un paio di quelle "molte universita'" di cui parli le conosco almeno marginalmente direi che incidentalmente quelle che si sono buttate su XP sono anche quelle in cui il design viene insegnato (sempre mai abbastanza e sempre troppo accademico, questo e' certo) e secondo me questo si che e' interessante.

Preferisco di granlunga chi non si riposa sulle sue vecchie conoscenze e cerca sempre ti tenersi aggiornato (in modo critico certamente).

Se andiamo a vedere il background delle persone che bazzicano l'ambiente XP troviamo tutti personaggi che a vario titolo si sono ritrovati invischiati negli anni in OOP, Smalltalk, Patterns et similia.

Non mi riferisco solo a "grandi nomi" come Beck e Cunningham ma anche ad alcuni dei professori che ora si sono "buttati su xp" in Italia :-)

E mi aspetto che queste stesse persone si interesseranno e insegneranno le prossime novita'/evoluzioni/tecniche quando si presenteranno perche' quantomeno sono stimolati, curiosi, desiderosi di progredire al contrario di molti che non insegnano, ad esempio, OOD perche' ai loro tempi non c'era e una volta sistematisi l'idea di continuare ad aggiornarsi e' andata a farsi benedire.

Questo vale ovviamente per tutti i campi, non certo solo per lo sviluppo software.

Certamente quanto scrivo non e' valido per tutti i casi ma almeno per i pochi che ho toccato con mano sembrerebbe proprio di si.
 
Ormai ho capito che con qualche abile (o, agile :-) eXPediente riesco a coinvolgere il buon Marco nelle discussioni :-)).

Universita': io ne conosco sicuramente da vicino piu' di una dove la progettazione del software non si insegna affatto, si insegna ovviamente tutta la matematica e la fisica di rigore, le reti, i controlli, si insegnano i linguaggi ecc ecc, ma di progettazione del software poco o nulla, mi verrebbe da dire di vera ingegneria del software poco o nulla. Pero' si insegnano le pratiche di XP (non proprio tutte, ci torno tra un momento). Alcune altre universita' non le conosco direttamente, ma me ne ha parlato chi ne e' uscito, oppure ne ho visto i risultati :-)).

Di per se', ovviamente, non c'e' nulla di sbagliato (anzi!) a spiegare i metodi agili, magari vorrei dire che in ambiente universitario sarebbe bello vedere anche gli altri e non solo XP, e sarebbe altrettanto bello concentrarsi sulle idee, valori, belief [di ogni metodo, anche non agile] e non solo sulle tecniche :-).
Dal mio punto di vista, sarebbe pero' compito del sistema formativo far capire realmente cosa vuole dire progettare (che, visto l'impazzare di greco-latinisti :-> sul mio blog, ricordo avere quel "pro" che ne determina il significato).

Purtroppo, devo dire che capisco bene come spostare il focus su XP renda la vita degli insegnanti piu' semplice. Quasi tutte le pratiche di XP si comunicano benissimo in ambiente universitario. Pratiche come TDD, Refactoring, Pair Programming, si spiegano con facilita' con esempi giocattolo (con pro e contro della situazione), si mettono alla prova con facilita' su piccola scala, e poiche' nelle universita' italiane (in media) ogni esame fa storia a se', tutto deve essere trasformato su piccola scala [ancora di piu' con l'organizzazione 3+2, ecc ecc]. Vedo invece difficile insegnare altri aspetti, come l'arte della metafora, ma qui ho l'impressione che neanche i vostri idoli :-) ci riescano particolarmente bene :-)).

Personalmente ho provato piu' volte a pensare come dovrebbe essere impostato un corso di software design "serio" a livello universitario. Dopo un po' di divagazioni piu' o meno ovvie (che spalmavano su un semestre le cose che normalmente insegno gia' nei miei corsi di design [per le aziende]) sono arrivato alla conclusione che per fare una grossa differenza, mi serviva una scuola di design, non un corso di design. Lo spiego leggermente meglio con un piccolo aneddoto.

Un anno fa circa ho proposto ad IEEE Software un articolo che riportava verso il software alcune idee di Donald Schon, sia sulla riflessione nel corso dell'azione che piu' in generale sul rapporto tra il progettista ed i propri materiali. Ci pensavo su da almeno un paio d'anni, ma non trovavo il tempo di consolidare le [poche] idee in un articolino. (Tra parentesi, dopo secoli dovrebbe effettivamente apparire sul numero di Settembre/Ottobre). IEEE Software e' una rivista refereed, quindi ogni articolo e' sottoposto all'approvazione di diversi revisori (nel mio caso 5). Un paio di questi hanno espresso, sin dalla prima versione, un'ottima opinione: hanno capito al volo la rilevanza dei temi trattati per i software designer. Uno mi ha anche dato un eccellente suggerimento su un lavoro di psicologia che non conoscevo e che mi ha permesso di migliorare la successiva revisione. Altri 2 rimanevano nel vago, volevano esempi piu' forti perche' l'articolo era secondo loro un po' troppo "concettuale". L'ultimo era infuriato, perche' parlavo di cose secondo lui fuori dal mondo. In particolare era infuriatissimo per una frase di Schon che citavo: "You have to develop your own sense of aesthetics". A suo avviso era assolutamente impossibile applicare al design del software il concetto di estetica, poiche' nessuno ne aveva (sic) stabilito le regole formali.

Eppure, il vero ruolo di una scuola di design dovrebbe essere proprio quello: far capire a chi progetta cosa e' in grado di esprimere (a livello funzionale e non funzionale) il materiale che plasma, nel nostro caso il software, rendere queste persone in grado di capire gli impatti locali e globali delle loro scelte, di ascoltare il proprio materiale mentre lo si plasma, ma in definitiva l'obiettivo deve essere quello di formare delle persone con una visione personale dell'estetica strutturale del software (non parlo di come indentare il codice :-)). [Sottolineerei che questo (non per il software :-) e' l'obiettivo finale di una buona facolta' di architettura].
Questo manca profondamente nelle universita' che conosco, perche' non e' affatto la missione delle facolta' informatiche. D'altra parte, manca l'esperienza e la forma mentis relativa alla maggior parte del corpo docente.
Calco la mano ed aggiungo che questo tipo di formazione sarebbe anche decisamente meno geek di quella abituale. La reale maturita' richiesta per capire le correnti estetiche all'interno dei diversi contesti e movimenti richiede, a mio avviso, di superare alcuni schemi di pensiero e di raggiungerne altri.

Tornando con i piedi per terra, nella mia intervista a Niklaus Wirth c'e' un brano che sembra qui particolarmente rilevante (qui e' Wirth che parla, l'italico e' mio):
"Professors typically spend their time in meetings about planning, policy, proposals, fund raising, consulting, interviewing, travelling, and so forth, but spend relatively little time at their drawing boards. As a result, they lose touch with the substance of their rapidly developing subject. They lose the ability to design; they lose sight of what is essential; and resign to teach academically challenging puzzles"

Come fa una seria cultura del design a crescere in questo contesto? E' ovvio che insegnare semplici pratiche code-centric diventa invece improvvisamente semplice, interessante, appetibile, va pure di moda e possiamo [casi concreti abbondano] pubblicare anche qualcosina o parlare a conferenze sul tema.

Ci tengo a sottolineare (gia' fatto, ma temo non abbastanza) che uno studio del design ed in generale della creazione del software non puo', modernamente, prescindere da uno studio anche dei metodi agili, almeno per le relazioni che hanno con il design.
Pero' io ho visto l'effetto di una di quelle realta' Smalltalkiane ora XPiste che citi, e non ne sono cosi' favorevolmente colpito (anzi :-).

Qui purtroppo avrei da dire qualcosina sulla "conversione agile" di alcune persone anche piuttosto famose [non quelle che citi, e nemmeno quelle legate alla realta' di cui sopra] ma penso che la terro' per me :-).
E' giustissimo aggiornarsi ed insegnare anche gli sviluppi piu' recenti. E' piu' discutibile quando si abbandona [o peggio si demonizza] completamente la cultura precedente per diventare i ferventi paladini di una nuova chiesa dove, si sa, e' piu' facile trovare un alto scranno libero :-)
 
Ormai ho capito che con qualche abile (o, agile :-) eXPediente riesco a coinvolgere il buon Marco nelle discussioni :-)).

:-D

Di per se', ovviamente, non c'e' nulla di sbagliato (anzi!) a spiegare i metodi agili, magari vorrei dire che in ambiente universitario sarebbe bello vedere anche gli altri e non solo XP, e sarebbe altrettanto bello concentrarsi sulle idee, valori, belief [di ogni metodo, anche non agile] e non solo sulle tecniche :-).

Non potrei concordare di piu'!! Ma dimmi una cosa: hai mai sentito qualcuno parlare di valori e belief nell'insegnamento dei metodi non-agili? Io no mentre nei due casi universitari che ho visto io questi temi sono il punto di inizio per i metodi agili. Valori e principi sono imprescindibili e sono argomento anche di tantissime discussioni (basta dare un'occhiata all'archivio della mailing list italiana per averne un esempio. Poi concordo con te che purtroppo per molti e' piu' comodo concentrarsi sulle pratiche e questo e' vero per qualsiasi argomento come giustamente scrivi anche tu. Pero' apri un qualsiasi libro dedicato ai metodi agili e se non parte dai valori li tratta comunque estensivamente. Non so quante migliaia di volte ho assistino a discussioni in cui gli agilisti partivano dal rpesupposto che senza i valori e i principi i metodi agili si risolvono in un semplice insieme di pratiche senza fondamento e l'altra parte sosteneva invece che questa e' la vera ingegneria del software: pratiche da seguire step by step in modo formale formale. Certo non tutti sono cosi pero' la mia impressione e' che nell'ambiente dei metodi agili questa e' la maggioranza mentre negli altri e', putroppo, la minoranza.

Ho anche pensato che il motivo di questa mia impressione fosse dovuto al fatto che negli ultimi 6 anni ho frequentanto maggiormente "ambienti agili" ma non credo sia questo il motivo dato che negli anni precedenti frequentavo altri ambienti (insomma, una certificaizone PMP scaduta ce l'ho ;-D)

Dal mio punto di vista, sarebbe pero' compito del sistema formativo far capire realmente cosa vuole dire progettare (che, visto l'impazzare di greco-latinisti :-> sul mio blog, ricordo avere quel "pro" che ne determina il significato).

Di nuovo siamo in sintonia (mal del resto abbiamo gia' concordato in passato che siamo daccordo su tutto ma abbiamo punto di partenza differenti).

Purtroppo, devo dire che capisco bene come spostare il focus su XP renda la vita degli insegnanti piu' semplice.

questo purtroppo e' vero per qualsiasi tema legato all'ingegneria del software. Aneddoto un paio di anni fa ho tenuto due lezioni all'interno del corso di ingegneria del software di un'universita' italiana (terzo anno) di introduzione ai metodi agili. Dato il tempo tutt'altro che abbondante (8 ore in tutto) ho dedicato alle pratiche solo le ultime due ore e mi sono concentrato su altri aspetti. Ho deciso anche di dare un'impostazione molto forte alle due giornate perche' il mio obiettivo era "scuotere" i ragazzi e stimolarli a vedere un altro punto di vista senza cercare di convincerla della botna' di uno o dell'altro. Abbia definito e discusso:

Formalismo -> illuminismo, Descarts, Hobbes, Leibniz,Formalismo, razionalismo, determinismo, meccanicismo Controllo centrale, gerarchia, predicibilità, provabilità, Babbage, Turing, von Neumann, Newell, Simon, Minsky -> Taylorismo

versus

Ermeneutica -> Husserl, Heidegger, Gadamer, Dilthey, Vygotsky, contestazione delle basi del formalismo -> Software Craftsmanship in cui gli obiettivi sono condivisi (software improvement) ma vi e' un rigetto delle assunzioni implicite dell’ingegneria del software a favore di creatività, arte, ruolo centrale dell’uomo.

I ragazzi purtroppo stavano letteralmente morendo (tralsciamo un attimo la possibilita' tutt'altro che remota che stessero morendo per colpa dell'insegnante e non dei temi...) e non hanno praticamente aperto bocca fino a quando non siamo arrivati alle ultime due ore relative alle pratiche come incarnazione di tutto questo bel discorso. Perche'? Perche' nessuno gli ha insegnato questi temi e non avevano gli strumenti per affrontare criticamente quella discussione.

Personalmente ho provato piu' volte a pensare come dovrebbe essere impostato un corso di software design "serio" a livello universitario [...] mi serviva una scuola di design

Bingo! :-)

Come fa una seria cultura del design a crescere in questo contesto? E' ovvio che insegnare semplici pratiche code-centric diventa invece improvvisamente semplice, interessante, appetibile, va pure di moda e possiamo [casi concreti abbondano] pubblicare anche qualcosina o parlare a conferenze sul tema.

Colpa degli insegnanti o dei temmi trattati? :-)

Qui purtroppo avrei da dire qualcosina sulla "conversione agile" di alcune persone anche piuttosto famose [non quelle che citi, e nemmeno quelle legate alla realta' di cui sopra] ma penso che la terro' per me :-).

Senza pensarci piu' di tanto me ne vengono in mente una decina anche MOLTO famose a livello internazionale ma dopo una prima "arrabbiatura" ho deciso che e' normale, fa parte dell'ordine delle cose :-)
 
[...] hai mai sentito qualcuno parlare di valori e belief nell'insegnamento dei metodi non-agili? Io no [...]

Marco: totalmente d'accordo. Forse l'unico momento in cui l'ingegneria del software "tradizionale" e' uscita da questo schema e' stato agli inizi del movimento dei pattern, che peraltro molti hanno "accusato" di contenere un elemento romantico (la ricerca della "qualita' senza nome") "at odds" con le argomentazioni tecnologico / scientifiche.
In generale, cio' che mi piacerebbe vedere in ogni approccio / metodo e' (almeno)
- quali sono i valori di fondo a cui si ispira
- quali sono le cose che ritiene vere (quelli che chiamo di solito belief, che trovo un termine carino ed espressivo)
- quali sono i contesti in cui si ritiene che quei valori abbiano senso (es. se i valori di fondo sono profondamente orientati all'ottimizzazione economica, o ad un particolare rapporto di customer intimacy, l'approccio / metodo potrebbe essere poco adatto ad una parte della ricerca scientifica, ecc)
- quali sono i contesti all'interno dei quali si ritiene che i belief abbiano senso.
Detto questo, sarebbe bellissimo capire, per ogni contributo dell'approccio / metodo, la congruenza con quanto sopra. Purtroppo i primi due punti, come facevi giustamente notare, sono praticamente assenti dall'ingegneria del software "tradizionale". I secondi due non sono cosi' assenti, ma spesso vanno un po' cercati tra le righe. Devo dire pero' che non mi sembrano cosi' presenti neanche nel versante agile (il che e' tutto fuorche' una scusante per gli approcci tradizionali :-). Da notare che gli ultimi due punti tendono a circoscrivere il raggio di azione di un approccio / metodo, che e' peraltro una cosa predicata da tempo dai veterani dell'ingegneria del software (es. Michael Jackson, Robert L. Glass).
Chi ha letto sin qui ed ha il bel libro di Armour (The Laws of Software Process) potrebbe aver voglia di rileggere il paragrafo "The Job of Methodology" che dice altre cose, in un modo o nell'altro comunque correlate :-).
 
Solo gli stupidi non cambiano opinione

Prendendo spunto da questa famosa frase, mi piacerebbe avere un po' di feedback su situazioni in cui ti è capitato di cambiare idea. Riguardo ad attività di architetto del software oppure opinionista di tendenza in campo informatico.

Qualcosa in proposito è già stato detto, ma nel frattempo ne è passata di acqua sotto ai ponti (non in questo assolato periodo estivo).

Forse è più appropriato un nuovo post.
 
Grazie a tutti per le risposte.

Per Carlo: Vista la mole di lavoro che già ho e la spesa prevista per il materiale mi concentrerò soprattutto all'inizio su ciò che può darmi il lavoro. Devo dire che la mia passione principale è l'architettura dei software (sto leggendo il libro di pressman, ho studiato OOP di Coad e UML distilled, dopo l'estate comprerò Design Pattern). L'unica cosa che non ho toccato ancora sono le tecnologie WEB. Devo dire che molte delle cose che ho fatto finora le ho fatte seguendo i tuoi consigli e mi sono sempre trovato bene. Per un certo periodo venivo soprannominato "l'oracolo" perchè ogni volta che i miei amici di università mi chiedevano una mano quando erano in acque profonde riuscivo a dare una soluzione sul momento o tutt'al più su argomenti che non avevo mai toccato come Java e CORBA (certo non mi sono mai vantato perchè poi ogni volta che leggevo un tuo articolo o mi aiutavi per qualche problemuccio mi accorgevo di quanta strada devo ancora fare :-((
Forse è per questo che odio i gestionali...


Per Michele: grazie per il consiglio, ma visto il lavoro che c'è da fare credo sia quasi obbligato :-))))
 
Uhm... scusate Carlo Pescio e Marco Abis, ma avete veramente presente la realta' universitaria? :-)
Quella con lezioni ad orari impossibili, appunti che mancano, informazioni tramandate per via orale, laboratori inadeguati... Che e' la stessa realta' fatta di studenti (anche molto volenterosi) che faticano tantissimo per apprendere il concetto di limite, o intuire il significato della parola "semantica", o mettere insieme il primo programma di mille righe per poi rendersi conto che programmare dev'essere qualcosa di molto diverso.
Durante i miei cinque anni non e' stato insegnato il C++, se escludiamo un paio di lezioni all'interno di un corso dedicato a tutt'altro. E se fosse stato insegnato, quanto avrebbero imparato gli studenti? Stiamo parlando sempre della stessa realta', quella in cui si studia da mane a sera, mica si programma.
Temo che ci si debba accontentare di neolaureati che soprattutto sappiano programmare, e che hanno una vaga infarinatura di ingegneria del software, come diceva Carlo qualche post piu' in alto. Sono pessimista? Non credo.
Un'ultima cosa che butto li', vediamo cosa dite. Il software viene sempre inteso come codice, quasi mai come applicazione finita. Quindi nessuno studia le interfacce utente, per fare un esempio. (Tra l'altro sono convinto che ben pochi saprebbero insegnare qualcosa a proposito... ma questo e' un altro argomento.) Secondo me all'universita' andrebbe insegnato in qualche modo che il software ha anche un valore "esterno", di prodotto finito.
 
Citrullo, ti rispondo (come di consueto :-) con una provocazione: se in cinque anni non insegnano praticamente nulla di tutto quello che ho elencato, perche' chiamarla Informatica o Ingegneria Informatica? Chiamiamola Matematica con Vago Indirizzo Applicativo oppure Ingegneria di NonSoChe', ma non e' Informatica ne' Ingegneria del Software.
Io da un programma *moderno* di Informatica trovo lecito aspettarmi un po' di quelle conoscenze (non tutte, ma almeno un po'). Alcune [es. teoria relazionale, normalizzazione] non posso credere che esista un serio programma con Informatica nel nome che non le insegni (se c'e', cambiamolo :-).
Sulle altre qualcosa mi aspetto. Ai miei tempi si dava una grande enfasi al paradigma funzionale ed al paradigma logico, al di la' del paradigma strutturato. Oggi vedrei meglio una enfasi maggiore sul paradigma ad oggetti e ad aspetti (mantenendo quello strutturato). Non mi pare che questo sia incompatibile con un ciclo di studi quinquennali.
Non mi infilo nella questione docenti, io so che ci sono persone di grandissimo valore che escono dalle universita' italiane e vorrebbero fermarsi ad insegnare, non posso credere che su alcuni argomenti fortemente teorico / metodologici non ci siano le competenze (posso capire su alcune problematiche piu' direttamente legate alla produzione industriale del software).
Il tema che citi lo inserirei in uno piu' ampio di "ingegneria del prodotto", che parli anche del valore economico del software, ecc. Che in alcune facolta' mi dicono si studi, ma non ho riscontri precisissimi. Poi temo che io sarei favorevole ad un programma di studi un po' piu' software-oriented e business-oriented, a costo di distanziarmi un po' dalle Scienze Naturali e/o dall'Ingegneria di QualunqueCosaMaCosiCosi, ma qui la cosa si complica :-)).
 
Post a Comment

<< Home