La risposta è facile: quelli che producono il software, ovvero i tecnici.

A loro viene chiesto di fare in tre o quattro mesi quello che hanno fatto in otto (come se prima ci fossimo grattati i cabasisi) e comincia la fiera dell'improduttività causata dal fatto che i PM&C devono fare le famose riunioni di allineamento, ovvero incontri volti a produrre un piano di azione e delle scadenze (sempre per i tecnici).

Perchè scrivo questo? perchè penso che si possa evitare o almeno limitare il clima veramente difficile da gestire.

Soluzione numero 1: dividere l'anno in due e quello che si manca a fine giugno è recuperabile solo in minima parte a dicembre.

Soluzione numero 2: legare gli obbiettivi non solo al budget economico, ma anche ad una valutazione  da parte della struttura produttiva che soffre di queste condizioni.

Sono convinto che questi due punti possano da soli far evolvere la situazione verso il meglio; conosco le possibili obiezioni specialmente riguardo al primo punto: è impossibile sono i clienti/committenti che non ci consentono di spezzare l'anno in due.

Posso non crederci? Posso ipotizzare che i clienti si comportano così perchè noi li abbiamo abituati/assecondati a fare così?

Posso ritenere che se un PM o chi per lui si presenta con una cosa da fare all'ultimo minuto e sa che riceverà per quello un guidizio che influisce negativamente sul suo premio di produzione pianifica meglio l'attività?

Se i tecnici non possono dire che una cosa è impossibile perchè possono dirlo gli altri?

Concludo con una delle osservazioni riportate nell'articolo che ho citato; quando si stabiliscono delle commissioni o degli incentivi bisogna sempre tenere presente che le persone faranno tutto il possibile e alla fine troveranno degli stratagemmi per riuscirci; strategemmi è diverso da soluzioni.

Fino a un mese fa venivano rilasciati i jar delle versioni con un ciclo di vita classico, rilascio delle major release (es 2.5) a cui seguivano le versioni con bug fix (2.5.1, 2.5.2, etc). Ed ecco che arriva l'annuncio, Spring Source cambia politica e dice che i sorgenti saranno rilasciati sempre cona la stessa licenza e sempre con su subversion, ma ci saranno solo i jar delle major release e delle minor release che verranno rilasciate entro tre mesi dalla data di rilscio delle mino release. Dopo i tre mesi ognuno fa da se' se vuole i jar in quanto sul subversion pubblico non ci sono ne tag ne branch quindi nessuna informazione per creare delle minor release comuni. Se si vogliono i jar delle minor release successive si deve sottoscrivere un contratto di supporto.

Credo che si tratti di un caso da manuale. Il sorgente rimane disponibile a tutti, puoi compilarlo, ma in realtà la libertà è solo apparente. Se dopo i tre mesi trovo un bug cosa faccio? Consulto la lista dei bug e se questo è stato corretto scarico i sorgenti e li compilo. Benissimo a questo punto che versione sto usando? boh. Come faccio a chiede supporto sui forum della comunità se in pochi ho nessuno usa la mia versione? E' facile intuire che se si vogliono creare delle applicazioni da metter ein produzione su cui garantire un supporto non si può procedere "liberi e belli" a meno di avere delle persone dedicate ai problemi Spring. Per cui ritengo che tale policy costringa di fatto a comprare il supporto da Spring Source. E' il classico caso in cui del sorgente te ne fai veramente poco, quello che conta è che hai un prodotto di qualità, gratis e con un supporto da parte della comunità. E' questo che dal punto di vista dell'utilizzatore conta, la libreria ed il supporto (per il management conta molto anche il fatto che è gratis); il sorgente spesso è uno specchietto per le allodole; un'altra cosa che conta è che la licenza consenta di vendere l'applicazione a sorgente chiuso (cosa che per esempio la licenza GPL non ammette).

Per fortuna le proteste della comunità hanno indotto Spring Source ad un cambio di rotta che ha portato al rilascio dei jar delle minor release fino alla versione RC della successiva major relase. Il problema si è notevolmente ridimensionato, a patto di essere sempre sulla cresta dell'onda ovvero di adottare l'ultima versione. Chi non se lo può permettere paga e tutto sommato è giusto così.

Vorrei concludere con una riflessione sui prodotti open source; l'analisi di una serie di casi mostra come storicamente tutti i prodotti che hanno dietro di sè una azienda che ne controlla lo sviluppo seguono un ciclo in cui la versione free (nel senso di free beer) subisce delle limitazioni del tempo; basti guardare Spring, MySQL, extJS e se ricordo bene anche le librerie QT. Il motivo è quasi sempre il profitto. Nel caso di prodotti open che sono sviluppati dalla comunità (Tomcat o Postgresql per esempio) questo non può succedere in quanto c'è una comunità di individui che spesso ricava profitto da altre fonti o in maniera indiretta. Lo svantaggio è che non ci sono persone dedicate allo sviluppo quindi le release possono essere diluite (anche se OpenBSD dimostra esattamente il contrario).

La scelta di un prodotto open source deve essere quindi effettuata facendo anche valutazioni di questo tipo in quanto i cambiamenti in corsa sono spesso sgradevoli e costringono ad un esborso economico improvviso oltre che ad una perdita di fiducia nel prodotto che si sta usando.

La prima è quella che quando chiedi una stima ti fornisce un numero di giornate sempre piuttosto basso (sono la fortuna dei commerciali e dei PM) e che alla fine entro la data stabilita qualcosa riesce a darti. il problema è quasi sempre il cosa. Spesso il software realizzato mostra una serie di bug evidenti che rivela che il grosso del lavoro è stato fatto, ma manca ancora la fase di rifinitura (ovvero quella di test serio). Cosa significa la maggior parte del lavoro? Significa che il codice all'80% circa c'è già tutto, non sono gestite le finezze ed i casi "estremi" (ovvero tutte quelle condizioni di input normali per l'utente, ma ignote allo sviluppatore).

Peccato che per l'utilizzatore questo significhi che il prodotto è al 40/50% non all'80, con le conseguenti lamentele del PM, del commerciale, del cliente.

Questo tipo di persona, se ha passione per il suo lavoro e non è uno che tira via (basta guardare come è scritto il codice per riconoscere il tipo), è di quelli a cui piace cambiare progetto e imparare sempre, a volte a ritmi decisamente elevati. Il motivo per cui non esegue i test è che ha già assorbito le basi della tecnologia e quindi ha già la testa che pensa al prossimo progetto, i test non aggiungono nulla o quasi al suo percorso tecnico.

Il secondo tipo di tecnico IT è quello che si potrebbe definire "Camillo Precisini" (il nome è preso da una favola per bambini che parla di un cane estramente meticoloso e preciso, fino all'esagerazione). Per lui il software non è mai finito e dopo la prima fase di realizzazione ne segue una, tendenzialmente infinita, di test, test, test. Difficilmente queste persone ti danno una data di fine (se te la danno) compatibile con le scadenze del progetto. La fine di solito la mette il PM che intima di rilasciare il prodotto, pena la crocifissione nella mensa aziendale. Il prodotto finito è decisamente più stabile e l'utente è più soddisfatto.

Quela dei due profili dovrebbe essere privilegiato(a parità di eleganza del codice e dell'architettura software)?

La risposta sembrerebbe essere il secondo.

Vorrei riflettere più a fondo.

Il tecnico smanettone consegna generalmente in tempo ed il suo semilavorato necessita di qualche giorno (ovviamente dipende dalla dimensione del sofware) per essere definito accettabile da cliente. E' il classico caso in cui il PM che conosce i suoi polli aggiunge un tot di giorni di margine e raggiunge l'obiettivo. Il tecnico preciso consegna quasi sempre in ritardo e comunque vorrebbe avere più tempo, vorrebbe avere più specifiche, etc,etc. Il software che consegna anche se più stabile, va comunque rivisto, in quanto la produzione software segue un percorso ciclico in cui ad ogni consegna si rivedono alcuni presupposti precedenti.

La cosa che va capita è che il software è buono solo se chi lo usa lo ritiene tale; inoltre essendo un prodotto umano è per definizione soggetto ad errori. Che senso ha consegnare un software tre mesi dopo e avere lo stesso gli utenti che lamentano (anche se meno rispetto a quello che sarebbe avvenuto tre mesi prima)?

In questo caso l'utente ti dice: me lo hai consegnato tardi e ci sono pure degli errori (per lui evidenti).

Gli errori ci saranno sempre, tanto vale consegnare in tempo e poi correggere gli errori.

I programmatori migliori di solito vorrebbero produrre un software che loro giudicano decente; la cosa che va capita è che:

1. Spesso il grado di qualità del software è percepito molto diversamente dall'utente
2. Non è detto che si debba arrivare alla qualità ottenuta al primo rilascio

La qualità del software, intesa sia dal punto di vista del codice che delle funzionalità utente, si ottiene solo dopo una fase di rodaggio in produzione quando si capisce cosa questo deve fare anche dal punto di vista dei dettagli operativi. Questo significa che è ottenibile sono dopo n iterazioni sviluppatore-utente.

In questo scenario il primo profilo spende meno tempo ed energia e nel lungo periodo, a parità di qualità, riesce ad essere più produttivo. Senza contare che nel mondo reale è tutto urgente ed il tempo non basta mai, per cui avere delle persone che investono tempo in cose che si potrebbero rivelare inutili o che potrebbero essere essere fatte fra n mesi può essere un elemento di freno oggettivo. Questo non vuol dire che non ci sia posto per i precisini, ma che questi dovrebbero cercare di bilanciare gli smanettoni (direi che un precisino e due smanettoni è una buona proporzione) per ottenere un compromesso accettabile.

Naturalmente i programmatori devono adottare tutti gli accorgimenti possibili per individuare i bug nei loro programmi e correggerli, ma non possono avere mai la certezza che il loro programma ne è immune.

La cosa è venuta fuori quando qualche tempo fa abbiamo scoperto un piccolo bug in un nostro programma che in determinate situazioni sbagliava alcuni calcoli. Abbiamo corretto il bug ed il cliente voleva la certezza che non si verificassero più errori. Abbiamo cercato di spiegare che non potevamo dare questa certezza (non siamo commerciali, noi...), ma il cliente non mi è sembrato molto convinto.

La sua obiezione era pressappoco su questi toni: come si fa ad utilizzare degli strumenti che non offrono certezze? Che da un momento all'altro potrebbero venir fuori con un malfunzionamento?
Come si fa a fidarsi di uno strumento semplicemente su una base statistica?
E' da diversi mesi che non si presentano più problemi quindi è probabile che neanche domani se ne verificheranno: è sufficiente questo per stare tranquilli?

A pensarci bene non è molto diverso dall'affermare: fino ad oggi non sono mai stato colpito da un meteorite, non c'è motivo per non credere che neanche oggi verrò colpito...

O no?!

1. I soldi
2. il tempo

Se queste due si è discusso a lungo per cui oggi voglio affrontare un altra causa, più rara, ma ben più insidiosa: il PM ex o finto tecnico. E' un mix quasi micidiale che richiede molta calma e fermezza per essere gestito.

Lo scenario è di solito è il seguente:

Arriva il PM con il progetto completo di importo, giornate uomo e scadenze (le stime le ha fatte lui, ha imparato a farle quando era tecnico). Ecco il "pacco regalo", tutto già fissato, c'è solo da lavorare. Con una sola piccola clausola, che il PM guarda, analizza e critica. E arrivano domande di questo tipo:

Ma questa funzione vuoi proprio farla così?
Ma sei sicuro di scegliere questa architettura?

Per poi passare in un crescendo quasi inarrestabile alle frasi del tipo

L'ho già fatto 10 anni fa nella metà dei giorni e dei soldi.

A questo punto la risposta è scontata: allora perchè non hai proposto la tua soluzione?

L'approccio da seguire, se si vuole evitare di arrivare ad una frizione inutile a tutti è quella di stabilire dei confini basati sulle responsabilità: se il progetto è in difficoltà per ragioni tecniche chi è il responsabile?

Lo si scriva nero su biano ed in cc a chi di dovere e la partita è chiusa. Si concorda un piano di scadenze e si lavora su quello.

Le cause di questi attriti non sono tecniche, sono caratteriali. I tecnici solitamente sono tali perchè amano avere il controllo delle cose che fanno, ovvero avere la sensazione (ed in vb6 si andavo veramente poco più in là) che quello che si produce sia assolutamente deterministico. Che cosa controlla un PM?

L'operato di altre persone (oltre ai soldi s'intende).

Non c'è niente di meno deterministico (e se poi si usa ancora vb6.....)

Come reagisce il PM? Cercando di imporre la sua autorità, con la speranza di un maggiore controllo.

Peccato che le persone riconoscono l'autorità (in senso lato, ovvero si creino dei riferimenti di cui fidarsi) e quelle imposte senza fondamenta creano un sentimento completamente diverso.

Che fare (se il PM non ci arriva da solo)?

L'unica speranza di lavorare sereni è quello di concordare costi e scadenze sensati e cercare di proporre soluzioni alle situazioni critiche, ovvero di cominciare a dare delle certezze.  Se il PM capisce di avere un  maggiore controllo e capisce anche che comportandosi in un certo modo può continuare ad averlo probabilmente cambierà atteggiamento.

Basterebbe capire che in progetto in cui ci sono n tecnici ed un pm che farà per forza di cose la maggior parte del lavoro? Per raggiungere lo scopo chi è che deve essere produttivo al 100%?

I tecnici, per cui o li si motiva o non si raggiunge l'obbiettivo.

Se non lo capisce (o non lo si vuole capire)....pazienza, peggio per lui; probabilmente rinuncerà ad una parte del suo premio di produzione (che di solito è più alto di quello di un tecnico).

"nessuno è insostituibile"

sia solo una mezza verità; in quanto è vero che l'azienda di una certa dimensione va avanti anche se una persona meritevole se ne va, ma è anche vero (e in questo moento non sto pensando a me stesso) che la "botta" spesso si sente (e nel 1999-2000 di botte ne ho sentite parecchie).

Il libro continua mostrando come i manager spesso agiscano in maniera semplicemente illogica perchè

"Le non soluzioni facili hanno molto più appeal delle soluzioni impegnative"

Molto bello anche il capitolo che spiega come sia sbagliato dare scadenze impossibili o mettere continuamente sotto pressione i tecnici.

Il tutto fa il paio con un paio di situazioni reali (una vissuta in pirma persona ed una no) che confermano ancora di più che non sono io il matto, ma chi crede che lo sviluppo software sia uguale al mondo della produzione industriale (e gestisce le persone come tali).

Mi chiedo come mai ci ho messo tanto a scovare questo libro.

Per chi fosse interessato sto parlando di "Peopleware" di Tom DeMarco - Timothy Lister

negli anni il testo del codice sorgente del sw è stato inserito all'interno di file di testo, con indubbi vantaggi. i file di testo si editano facilmente con programmi elementari che si trovano ovunque. i file di testo possono essere manipolati facilmente dai compilatori e dagli analizzatori sintattici.

l'osservazione che voglio fare è che la rappresentazione fisica del testo del codice sorgente è da sempre il file di testo, ma oggi non c'è più una motivazione a questo e il tempo è maturo per eliminare vincoli e side effect di questo legame. gli strumenti utilizzati dagli sviluppatori sono sempre più grafici e la potenza di calcolo consente di gestire una vera astrazione tra cio' con cui lo sviluppatore ha a che fare (il testo o quel che sia il sorgente) e la sua rappresentazione fisica.

Quel che voglio discutere è che l'utilizzo di un file di testo per rappresentare il codice sorgente è stato in passato una scelta obbligata dai mezzi utilizzati dagli sviluppatori per creare il codice. Oggi questo vincolo è giustificato solo dalla storia.

Scrivere codice in un file di testo ha portato a un sacco di conseguenze che molti sviluppatori danno, senza motivo, per scontate:

• il codice viene letto dallo sviluppatore sequenzialmente. non interamente, ma comunque si viene portati a leggerlo dall'alto verso il basso. Strutture non sequenziali (condizioni, cicli) vengono per forza appiattite. metodi e funzioni vengono messi involontariamente in ordine.
• L'eredità dei parser di file di testo è che la posizione nel file di testo (non nella struttura come sarebbe più corretto) di un comando spesso determina un comportamento diverso.
• Gli sviluppatori si sono creati nel tempo convenzioni di tabulazione per facilitare la lettura e best practice di leggibilità (80 caratteri!!!!!) determinate dai display di 20 anni fa.
• Le grammatiche stesse dei linguaggi di programmazione impongono l'utilizzo dei file di testo per demarcare porzioni di codice e della struttura del software.
• alcuni linguaggi di programmazione hanno fatto di regole di tabulazione delle regole grammaticali vere e proprie.
• i limiti degli strumenti di sviluppo sono spesso legati alla struttura dei file di testo del codice

se oggi dovessimo inventare uno strumento per sviluppare software (attenzione, non ho detto per scrivere codice!) cosa proporremmo? il testo è indubbiamente un canale di comunicazione estremamente immediato per l'essere umano, ma dobbiamo per forza legarci a un file di testo? non è possibile pensare al codice sorgente come un mare indistinto di porzioni piccole di testo che si integrano a formare la base di codice di un sw? non cadremmo sicuramente nell'errore di considerare il confine del file di testo come un confine del sw, come spesso accade. certo perderemmo la possibilità di utilizzare uno stupido editor di testi per lavorare sul codice, ma non è forse meglio è più efficace avere un ambiente di sviluppo che dia tutti gli strumenti necessari a navigare nel codice, facendoci dimenticare della rappresentazione fisica del sorgente?

lancio quindi la proposta: proviamo a elencare gli scenari e le possibilità che si potrebbero avere abbandonando il vincolo legato alla memorizzazione su file di testo?

Ho iniziato la mia carriera nello sviluppo del sw nel 1995. Non proprio la carriera, poichè ci sono entrato da studente all'istituto tecnico. ok, i primi 5 anni sono passati con poca significatività. Sufficienti a formarmi su Turbo Pascal e Assembler. Good. I fondamenti di ciò che so ora li ho appresi in quel momento. Gran finale con una tesina di maturità (vecchia maniera) sull'Object Orientation. Col senno di poi, non ci avevo capito granchè. Bertrand Meyer non era facile come autodidatta. L'ho apprezzato solo in seguito.

I primi due anni di università ho rischiato di retrocedere. Si esce dalle superiori pensando di saper tutto, si trova un'università che non riesce a smentirti. Tristezza. Una inutile esperienza in Modula2 e una inesistente preparazione su C++.

Terzo anno, un corso su Java, il primo progettino serio. Oh. Negli anni seguenti infilo tutti gli esami possibili con un progettino di sviluppo. Gioco con il Lisp. Conosco il mondo del web sviluppato in Java con le servlet e le jhtml (quando ancora le jsp si chiamavano così).

Inizio a lavorare alla ME&S, una microsocietà di sw specializzata in strumenti di eLearning che lavora con Toolbook, una piattaforma di RAD per elearning con un linguaggio di scripting estremamente vivace. Evviva, imparo cosa significa lavorare nell'informatica e cos'è la consulenza. è il 1998. Qui proseguirò a sviluppare in Java. Qui nel 1999/2000 ci convertiamo tutti al Javascript. Venivamo dal mondo di Toolbook, interattivo, multimediale (era un concorrente di Director, l'antesignano di Flash). Non potevamo che cercare di fare altrettanto con Javascript. Ed ecco che in quei lontani anni sviluppiamo applicazioni Javascript che farebbero impallidire una applicazione AJax moderna. Qui nasce tutto il mio sapere Javascript e tutto cio' che oggi mi consente di parlare a braccio di come funziona un browser.

Dopo aver mollato una tesi mezza iniziata di intelligenza artificiale, mi infilo in una tesi sul sw testing, per la quale anzichè far testing devo sviluppare una gran applicazione in C++. Un tool per la generazione automatica di casi di test che integra un pre-compilatore, un esecutore simbolico, un valutatore di espressioni algebriche, un analizzatore di grafi e forse altro che ho rimosso.

Sviluppo la tesi in contemporanea con il master IT del CEFRIEL e mi guadagno due titoli con una fava. a fine master, inizio a lavorare al CEFRIEL nell'area di Ingegneria del Software. Coltivo una specializzazione sulla piattaforma Java Enterprise, su cui tengo un po' di corsi sia in CEFRIEL sia in Politecnico. Approfitto di un progetto per giocare anche con la piattaforma Eclipse e prendermi un po' di competenze anche nello sviluppo su architetture a plugin.

Col tempo, perdo dimestichezza col C++. Nel 2005 però derivo dal mondo Java per circa 4 mesi, sviluppando in C# una architettura per l'integrazione di strumenti di domotica sul Windows Media Center. Si parla di Universal Plug & Play.

Lascio il C# e mi infilo nel Python per un po' di 2006. si sviluppa (giocando anche con Scrum) una piattaforma per la predizione di flussi di traffico sulla rete di milano. Non male.

Ultimamente ho perso un po' il ritmo, poichè son passato dalla parte oscura della forza (sono PM). Non mi va di aspettare oltre a dir la mia. Oltre suonerebbe solo come un rimpianto. Spero valga il penny.

I ragazzi si cimenteranno nello sviluppo di una applicazione per iPhone senza un attimo di tregua, accettando anche suggerimenti dagli spettatori.

Sia sul loro sito sia sull'intervista apparsa oggi su Punto Informatico, i quattro citano Extreme Programming come se fosse uno sport estremo.
Forse non sanno che proprio Extreme Programming è nettamente contrario ad un orario di lavoro "estremo"...

In ogni caso, mi sembra una buona mossa pubblicitaria. In bocca al lupo!

Se nel caso della produzione la metafora poteva sotto qualche aspetto reggere, una volta che si parla di manutenzione la metafora è inapplicabile.

Provo ad elencare le differenze con una serie di domande.

Vi immaginate di dover chiamare per forza l'artigiano che vi ha fatto il lavoro (elettricista, muratore, idraulico, etc) per qualsiasi modifica?

Vi immaginate di dover pagare un contratto di assistenza annuale per i problemi con l'uso della casa?

Vi immaginate di sentirvi dire dopo tre/cinque anni che la vostra casa è obsoleta e che ne vuole una nuova?

Mi pare che sia sufficiente.

A mio parere assimilare il processo di realizzazione di un software al processo di realizzazione di un edificio è decisamente fuorviante e ci sono più divergenze che similitudini.

Consideriamo come viene fatto un edificio: si parte dal progetto che viene approvato (a volte accompagnato della presentazione di un plastico) e da lì si comincia a costruire. Una volta che si comincia alcune cose diventano immutabili, per esempio non è più possibile (se non con costi ed oneri esagerati) spostare la costruzione o cambiare forma alle fondamenta. E' possibile cambiare i particolari, le collocazioni di alcuni muri, ma la natura dello stabile rimane quella del progetto. La costruzione viene fatta da una serie di figure completamente diverse e spesso molto specializzate, chi tira su i muri difficilmente monta gli infissi o fa l'impianto elettrico o quello idraulico o posa i pavimenti. L'architetto o l'ingegnere o il geometra vanno in cantiere per assicurarsi che il direttore lavori segua fedelmente il progetto, ma sicuramente "non vanno alla betoniera". Un altro fattore importante è l'interscambiabilità, un muratore un giorno fa un pezzo di muro che il giorno dopo può essere finito da un collega, senza particolari passaggi di consegna.

In sostanza tutto procede secondo logiche preordinate e basate su standard accettati. (Se qualcuno pensa che nei cantieri edili ci sia il caos legga quello che segue).

Nell'informatica invece non accade nulla o quasi di tutto questo. Il committente spesso aprrova un progetto non conoscendo i dettagli di cosa verrà fuori e capisce cosa vuole solo quando vede funzionare un pezzo di software. Ne risulta che spesso è necessario un ciclo di prototipi e rilasci per tarare il tiro. Chi di noi andrebbe ogni giorno in un cantiere cantiere che ha commissionato dicendo "mi sposti la finestra più in qua" o "le piastrelle che ho scelto e che avete montato non mi piacciono più" o ancora "mi sposta la casa altri di 30cm dalla strada"? aggiungendo "tanto quanto vuoi che costi"?

Chi costruisce una casa sa benissimo che dopo che un pezzo è stato fatto c'è un costo ben preciso per buttare giù e rifare. Chi commissiona un software evidentemente no.

Un altro aspetto è la specializzazione che nell'informatica è molto meno sviluppata, proviamo a lasciare una classe o anche una funzione a metà ed assegnare ad un altro programmatore il compito di finirla; quanto tempo ci vuole per la presa in carico di quanto già fatto? Inoltre spesso unprogrammatore svolge diversi compiti (design dell'interfaccia grafica, modellazione/definizione di parti della base dati, etc)

Un altro indicatore che indica quanto la produzione del software sia diversa e più arretrata rispetto alle costruzioni edili è la presenza dei building block ovvero dei componenti riusabili. Nell'edilizia si usano, mattoni porte e finestre già fatte, nell'informatica molto meno. Cosa succederebbe se un giorno entraste nel cantiene dove stanno costruendo casa vostra e vedeste un muratore che con un camino acceso fabbrica dei mattoni? Immaginiamo il dialogo:

Noi: Buongiorno, cosa sta facendo?

Muratore: Buongiorno, sto facendo i mattoni per costruire la casa

Noi: Perchè?

Muratore: Sa, quelli che sono in commercio non mipiacciono tanto, poi hanno quegli spigoli così ruvidi, me li faccio io così faccio prima e sono come mi servono.

Il risultato sarebbe: fuori dal cantiere a calci nel sedere.

Nell'informatica molto pochi si scandalizzano se qualcuno nel 2008 si fa un package di logging in java o in .net eppure la fine dovrebbe essere quella del mutatore sopra citato.

Un'altra differenza sostanziale è che chi comincia a programmare fa una carriera in cui pian piano diventa coordinatore e poi project manager o commerciale; quanti muratori-architetetti o elettricisti-ingegneri conosciamo?

Si conclude qui questa riflessione sul processo di costruzione software e sulle sue differenze rispetto al processo di costruzione edile. Tutti i fattori elencati fanno parte della fase costruzione, manca ancora la fase "manutenzione e post vendita", ma credo che già si intuisca come parlare di software architect sia una cosa che non ha fondamento reale. Nei prossimi articoli proverò ad illustrare altre differenze e delle metafore più appropriate.

Il manifesto dello Sviluppo Software Agile

Diciassette anarchici concordano:

Stiamo portando alla luce metodologie migliori di sviluppo software facendolo in prima persona e aiutando altre persone a farlo. Attraverso questo lavoro siamo arrivati a concludere:

• Individui e interazioni piu’ che processi e strumenti.
• Software funzionante piu’ che una documentazione esauriente.
• Collaborazione con il committente piu’ che negoziazione contrattuale.
• Rispondere al cambiamento piu’ che seguire un piano prestabilito.

Significa che, nonostante apprezziamo gli aspetti che si trovano sulla destra di questi punti, diamo maggiore valore agli aspetti citati alla sinistra.

Seguiamo questi principi

• La nostra piu’ alta priorita’ deve essere quella di soddisfare i requisiti del committente attraverso precoci e continui rilasci di software di qualita’.
• Non bisogna temere il cambiamento dei requisiti, anche se avviene in fasi avanzate dello sviluppo. I processi agili sfruttano il cambiamento per il vantaggio competitivo del committente.
• Consegnare software funzionante in maniera frequente: ogni paio di settimane o al piu’ ogni paio di mesi, con una preferenza per scale temporali ridotte.
• I committenti e gli sviluppatori lavorano insieme quotidianamente per tutta la durata del progetto.
• E’ necessario basare i progetti su individui motivati. Bisogna dare l’ambiente e il supporto di cui necessitano e avere fiducia in loro sul fatto che il lavoro verra’ portato a termine.
• Il piu’ efficiente ed efficace metodo per trasmettere le informazioni al team e per far si che esse circolino al suo interno e’ la conversazione faccia a faccia.
• Un software funzionante e’ la principale misura dello stato di avanzamento del progetto.
• I processi agili promuovono un’attivita’ di sviluppo software sostenibile. Promotori , sviluppatori ed utenti devono essere in grado di mantenere un passo costante a tempo indeterminato.
• La Semplicita – l’arte di massimizzare il lavoro non svolto – e’ essenziale.
• Le migliori architetture, i migliori requisiti e progetti emergono da team auto-organizzati.
• Ad intervalli regolari, il team deve riflettere su come diventare piu’ efficace, e dunque regola ed adegua il suo comportamente di conseguenza.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

www.agileAlliance.org

La nuova SDK chiamata m5-rc14 presenta le novità seguenti:

• Nuova interfaccia utente
• Aggiunto un layout per animazioni
• Geo-coding: una libreria grazie alla quale è possibile tradurre gli indirizzi in coordinate e viceversa
• Nuovi Codec multimediali: Aggiunto il supporto ai file audio OGG Vorbis, MIDI, XMF, iMelody, RTTL/RTX, e OTA
• Aggiornato il plug-in per Eclipse

Potete scaricare la nuova SDK da qui, oppure leggere la notizia ufficiale.

Infine, se siete interessati alla nuova interfaccia, ecco una lista di screenshot.

Fonte: Engadget

Uno degli step fondamentali nello sviluppo di RIA e software desktop è la produzione di documentazione, studio sulla strada da percorrere e, quando il budget lo permette, integrazione con nuovi servizi e tecnologie.

Il 2007 è stato un anno ricco di novità sul campo software e ci ha reso più "ricchi" a livello di opportunità e possibilità di lavori / idee / ricerche.

Il 2008 sarà l'anno per poter integrare quanto di buono studiato e analizzato l'anno precedente e già ad oggi stiamo ricevendo grosse gratificazioni dai nostri clienti per proposte innovative e interessanti studiate ad hoc nel proprio campo lavorativo.

Infatti, ci proponiamo più come partner tecnologico che come e veri e propri fornitori e questo modo di porci ai nostri "partner" ci permette di dare innovazione continua e mirata.
Un plus che ad oggi può fare veramente la differenza!