Brooks on Design!

Ho ascoltato con vivo interesse un intervento di Fred Brooks all'università del North Carolina.
Non tutto condivisibile ma prezioso e divertente.
Potete scaricare il file da qui.

Ho notato con piacere che Fred Brooks attribuisce al designer (al great designer) un ruolo attivo e non un mero scrivano (vedi precedente post)
Il designer deve saper cogliere cosa costruire (dando per scontato che poi sappia anche il come) e quindi aiutare il cliente a capire ciò di cui necessita.

Buon ascolto.

Framework

Due mesi spesi insieme al team a lavorare ad un progetto vincolato tecnologicamente (e commercialmente) ad un framework roboante, farraginoso e pretestuoso. Non intendo rivelarne il nome anche perché i suoi limiti sono comuni a quelli di molti altri framework (ma se non provvederanno a riscriverlo ne sentirete presto parlare come di un clamoroso flop).
I limiti dunque. Lasciando da parte le scelte architetturali (comprese tra l'altro molto tempo dopo) e concentriamoci sulla documentazione. Questa per un buon 80% è fatta a "libreria", ovvero in maniera descrittiva sono riportati tutti i metodi con relativa short description. Serve a ben poco perché ad istinto i developer provavano a piegare le funzionalità del framework dentro al loro framework mentale, quello cioè a cui sono abituati a lavorare. Nessuna indicazione sulle scelte architetturali, di come affrontare problemi ricorrenti che il framework dovrebbe risolvere in maniera più semplice (altrimenti a che serve). Niente. Nada.
Solo una accozzaglia di metodi da richiamare con una serie di dipendenze non documentate e fonte di frustrazioni per l'intero team.
Per il caso particolare, da buoni informatici ci auguriamo l'estinzione (o una buona ristrutturazione, ma da mani diverse...:-)) perché non è solo una questione documentale ma questa quando è fatta con i piedi è indice che sotto sotto c'è qualcos'altro, e infatti...
Non è una ripicca, ne vale il tempo di altri colleghi.

Formazione

Di recente ho seguito una serie di corsi su svariati argomenti. Quello che ho notato in maniera pressoché costante è che i trainer tendono a dare informazioni piuttosto che strumenti di reale improvement (formazione).
Difficile che ti dicano come fare una stima, come migliorare la comunicazione, ecc. E qui siamo nel campo della tecnica, delle cose che chiunque (o quasi) può apprendere!
Il guaio è quando poi si pretende di dare lezioni su argomenti che sollecitano la parte pre-cablata di ognuno di noi, ovvero con il tuo modo di essere.
Nel campo della leadership, ad esempio, si omette per ingenuità (o al contrario per scaltrezza) che non tutti possono essere leader, che la leadership pesca nel modo di essere e vivere di ognuno di noi e che nessuna tecnica può mai (nell'ordinario) farci trasformare in leader vincenti (ma avete mai letto certo tipo di pubblicazione a riguardo?)
Si possono avere dei lievi miglioramenti, aggiustamenti, limature. Mi chiedo: ma non sarebbe più onesto dire a queste persone che è meglio fare altro, valorizzarsi in altri ambiti?

Perché Bill?

Apprendo la notizia con stupore. Nei giorni scorsi Bill Gates ha detto di sperare di non essere l'uomo più ricco del mondo.
"Desidero non esserlo. Non c'è niente di buono che derivi da ciò", non ama l'attenzione che arriva dall'essere il più ricco del mondo.
Tertium non datur: o è rimbecillito o continua a fare business.
Lascio a voi fare le opportune considerazioni.
Fatemi capire, vi prego.

Borland(ia)

La notizia è recente, ma già molti analisti si arrovellano sul futuro che si schiuderà dal nuovo business scelto dalla Borland: si passa dai tool per creare applicazioni a tool per gestire le applicazioni (per chi ama le sigle: IDE to ALM).
L'azienda si reingegnerizza, nuovi competitor, nuove linee di prodotti,...ma dietro l'opportunità di business intrapresa dalla Borland (e naturalmente ci auguriamo che gli affari vadano ancora meglio di prima) forse c'è un altro dato, che forse trascende perfino le interpretazione di quei "marpioni" della Borland.
Voglio dire che sembra sempre più inclinata verso il management la bilancia del binomio management/build, che stiamo entrando in una fase ove il mercato della realizzazione del software tende verso la saturazione generando una simmetrica necessità di impedire tale saturazione con la gestione dell'intero ciclo di vita del software.
In questa prospettiva - fatto salvo che abbiamo visto giusto - Borland forse è solo l'anticipatore di una nuova tendenza di mercato.
Staremo a vedere.

Il cliente non ha sempre ragione

Uno dei cavalli di battaglia delle metodologie agili è la presenza o comunque il coinvolgimento costante del cliente. Pur trovandomi d'accordo in linea di principio, la realtà che quotidianamente sperimento (ma credo di non essere l'unico) è purtroppo un'altra.
Vi immaginate il cliente continuamente alle spalle? Quello che non si capisce è che il team di sviluppo deve ascoltare ciò che il cliente vuole ma realizzare ciò che il cliente ha veramente bisogno. Questa è una lezione costante che tende a valorizzare il team e a portare il cliente su posizioni più adeguate.
L'implicazione immediata è che l'attività di analisi smette di essere una pura trascrizione di requisiti diventando un momento di riflessione sul "significato" del sistema da realizzare.

Index tomisticus

Grande quanto sconosciuto nel nostro ambiente questo pioniere del "literary and linguistic computing". Parlo di padre Roberto Busa S.J., ormai ultranovantenne.
Nel 1949 incontra a New York Thomas Watson Sr., amministratore delegato della IBM. Incontro proficuo che gli consentirà di realizzare sulle macchine della IBM il suo chiodo fisso: una colossale analisi sistematica della struttura del linguaggio di S. Tommaso registrata su 16Km di nastro, pubblicata tra il 1974 e il 1980 in 56 volumi e ora disponibile su Cd-Rom. Senza il timore di esagerare credo che quest'opera (appunto l'Index Tomisticus) segni la nascita dell'informatica linguistica.
In un afoso agosto riminese del 2000 ebbi il piacere di scambiare due chiacchiere con padre Busa, dopo la presentazione del suo libro "Dal computer agli angeli", ove l'autore ha trovato il tempo di confezionare in 1.261 "momenti di pensiero" giudizi puntuali sull'informatica, sull'AI, Internet e sul rapporto attivo tra uomo e macchina.
L'invito alla lettura è scontato da parte mia e per dare un assaggio inerente al nostro lavoro padre Busa sostiene che la programmazione è un atto di sapienza, quella sapienza che presiede all'organizzazione e che secondo l'Aquinate è «il modo con cui si produce qualcosa, cioè lo si pone in essere organizzandolo bene».
Il rapporto tra programmazione ad oggetti e la logica aristotelica/tomista è uno studio che prima o poi porterò a termine e spero di darne evidenza anche in questo spazio.

Analisi e sintesi

Il lavoro scientifico è orientato verso due direttrici: "una tendenza analitica a scomporre il complesso in oggetti semplici (ricerca della spiegazione, del come) e una tendenza opposta, sintetica, a collegare più oggetti integrandoli in unità più grandi, che non sono la pura collezione degli oggetti componenti, ma per effetti dei mutui cambiamenti acquistano un significato non prevedibile da una pura descrizione del componente: questa organizzazione in unità più complesse corrisponde a una ricerca di significato".
La scienza galileana è tutta permeata da una tendenza analitica e solo dai recenti studi sul paradigma della complessità è emerso una tendenza alla sintesi allargando la ricerca in molti campi non ultimo la scienza informatica. Un esempio chiaro è la realizzazione di architetture software che guidano poi lo sviluppo dei sistemi informatici. Mi sottraggo dal dare una formale definizione di architettura per ragioni innanzitutto di incompetenza, ma l'ossatura di un sistema software, dunque l'architettura portante, segue la direttrice della "sinteticità" intesa come interpretazione del significato che si vuole dare al sistema. A posteriori è assolutamente arduo spiegare il "cosa" di un sistema semplicemente consultando l'elenco dei componenti costituenti, bisogna piuttosto vederne la struttura, le relazioni e le dinamiche in essa contenuti (e qui che si misura la bontà della documentazione, spesso bistrattata e quando presente perfettamente ridondante rispetto all'architettura e quindi inutile, oltre che un peso per chi deve leggerla e/o studiarla).
Metodologicamente l'analisi guida l'esplorazione dei mattoni costituenti (le classi, i componenti) e la sintesi li agglomera dando forma e significato. Entrambe sono due momenti distinti dell'attività di design architetturale.
In continuità con il post precedente, non credo sia inutile mutuare dalla scienza (quella vera) metodi, pratiche e suggerimenti. Dirò di più: esiste un solo metodo di indagine della realtà (per la scienza, per la biologia, per gli ingegneri,...) e molte modalità applicative diversificate dalla fetta di realtà indagata e dagli strumenti adoperati.

Progettazione galileana

Soprattutto all'interno del paradigma ad oggetti, la fase di design (molto discussa su cui è difficile trovare unanimità sul suo reale significato - può destare meraviglia ma è così), dicevo durante questa fase l'architetto è chiamato ad effettuare scelte e ad applicare regole che molto hanno a che fare con il metodo scientifico preconizzato da Galileo (e Bacone e da tanti altri e sui cui in un prossimo post proverò a dire qualcosa). Vediamo dunque le similitudini di metodo:
Astrazione. Senza andarne a cogliere il significato profondo, per un fisico questo significa far risultare dall'osservazione il passaggio dalla realtà ai simboli attraverso i quali la dominante osservata è quantificata (l'astrazione scorpora l'osservazione dai dettagli ritenuti non essenziali). Analogamente per l'architetto software quei simboli saranno i costrutti UML che nel loro insieme veicolano il significato del sistema (anche l'architetto effettua una scelta determinante nel quantificare gli aspetti essenziali da quelli secondari).
Modello. Dall'astrazione segue per il fisico un modello che semplifica il fenomeno osservato incapsulandolo in un "oggetto" molto più maneggevole e riproducibile su cui fare inferenza. Dall'altra sponda, l'architetto crea modelli software (che semplificando possiamo considerare artefatti molto tangibili) per aiutare a capire e su cui ragionare. Una immediata conseguenza è che si riduce l'ampiezza di indagine e si gestisce la complessità intrinseca in maniera diretta.

Il fisico poi procede alla ricerca di una legge che descriva il fenomeno, per poi passare agli esperimenti per giungere finalmente ad una teoria. Molto meno impegnativamente un architetto è chiamato a generalizzare i risultati - esperienza e sudore - per poter riusare l'esperienza. Questa è un specola di osservazione interessante da cui vedere la nascita dei pattern di design.

Giova sottolineare che sia i contenuti (scontato) sia gli strumenti (scontatissimo) delle due discipline sono assai differenti e a favore degli architetti (non essendo un fisico :)) vedo l'utilizzo facile di UML inteso però come strumento che fa leva sulle umane capacità di "visualizzione" dei concetti.
Certo loro hanno tutta la matematica che li sorregge...

Tuples

Qualcuno (offline. Vi invito naturalmente a fare uso dei commenti) mi ha chiesto maggiori dettagli sul significato delle tuple (citate nel precedente post).
Dato che ho sottomano Nice provo a dare qualche esempio non prima però di una informale definizione: una tupla può essere vista come un insieme di valori referenziabili tramite un solo tipo. Ad esempio t1=("Tuples", 5, 't') è una tupla del tipo (String,int,char)
Si può dunque avere un metodo che ritorni più valori:

(int,int) minMax(int x, int y) = x < y ? (x,y) : (y,x);

oppure una ricerca che ritorni l'esito e l'eventuale posizione:

(boolean,int) search(int[] a, int val) { for( int i: 0..a.length-1) if( a[i] == val ) return (true,i); return (false,0); }

Un qualcosa di più interessante sono i slick-iterator (iteratori smart embedded) sulle tuple che combinati con i metodi anonimi (simili alle classi anonime) possono dar vita a codice snello e pulito:

List<(String, String)> tuples = new ArrayList(); tuples.add(("a", "1")); tuples.add(("b", "2")); tuples.foreach ( ((String letter, String number)) => println("letter: "+letter+" number: "+number) );

Il codice merita qualche secondo di "osservazione" per superare il gap sintattico ma poi tutto risulta semplice. L'unico punto di attenzione è la definizione "a volo" di un metodo anonimo (tramite l'operatore =>) alla cui destra compare l'implementazione.

Considerazione
A mio avviso Nice è un utile supporto a Java, non credo che farà "tremare" il mercato. E poi, da un altro punto di vista (come riportato anche da Bonniot, l'autore del linguaggio) è vera l'affermazione di Alan J. Perlis (il primo ad essere insignito del Turing Award nel 1966): "A language that doesn't affect the way you think about programming, is not worth knowing."

Ancora sui linguaggi

A proposto della similitudine di alcuni linguaggi, ne aggiungiamo alla lista altri tre (questi hanno interessanti particolarità):

• Nice, come riportato nel sito "Nice is a new object-oriented programming language based on Java. It incorporates features from functional programming, and puts into practice state-of-the-art results from academic research. Among the advanced features: parametric types, anonymous functions, multi-methods, tuples, optional parameters to methods, design by contract, detection of many errors during compilation (in particular, concerning casts and null references). This results in more expressivity, modularity, and type safety."
• D, come riportato nel sito "D was conceived in December 1999 by Walter Bright as a reengineering of C and C++, and has grown and evolved with helpful suggestions and critiques by friends and colleagues."
• C Omega, di casa Microsoft che si basa su C# (sbilanciato verso la concorrenza ed un intelligente accesso ai dati)

Difficile mettere questi linguaggi (e C/C++/C#, Java) in coordinate ortogonali...la cosa più semplice è provare ad "ortogonalizzare" la caratteristica dominante in ognuno di essi. Se questo esercizio sarà risolto emergerà lo specifico (=identità, particolarità, valore) di ognuno di essi.

Agileft

Ho una marcata tendenza a relazionare tutto (quel poco) che conosco. Generalmente mi giustifico (e quando ci riesco?) in questo modo con chi continuamente mi fa notare la mia abilità di "buttarla sempre in politica" anche quando si parla di informatica (e qualche post ha già evidenziato questa che molti considerano una tara...bah).

Dunque, i metodi agili sono di sinistra? Autorevolmente Zio Bob esprime una sua opinione attraverso un simpatico episodio (ha un blog per parlare di politica). Non è affatto un caso isolato, anzi.

Io sono fermamente convinto che moltissime mode, tendenze, filosofie (non parlo innanzitutto di persone) che ci coinvolgono giornalmente nel nostro lavoro hanno una forte relazione con le idee politiche, e questo non è un male in sé...è quando tutto questo diventa volutamente implicito che si abusa di ipocrisia.

XP: Silver Bullet?

Arcifamoso è l'eccellente articolo di F. Brooks: No silver bullet: Essence and accidents of software engineering, IEEE Computer, Vol. 20, n. 4, Apr. 1987
Ho provato a ripensare ai processi agili e in particolare all'Extreme Programming (XP) che io considero una "pallottola d'argento" spuntata (so bene di dire qualcosa di politicamente scorretto e non mi fa piacere. Perfino un guru come Fowler non considera XP un "silver bullet", e questo rende il presente post davvero minimale e personalissimo), per dare ragione ad alcune perplessità.
Innanzitutto si tratta di una rivoluzione terminologica e non concettuale. Affonda le sue radici in un solco già ben definito dell'ingegneria del software in particolare in tutta quel filone che ha praticamente rimosso il modello a cascata. Alcune sue pratiche come il pair programming, refactoring, collective ownership, coding standards non sono delle novità, e possono essere first-citizen in molti ambiti. E qui veniamo al secondo punto: estremo mi pare che significhi (sotto la scorza della propaganda) esattamente il mettere tutte le pratiche proposte in un processo universale che eliminerebbe alla radice problemi quali gestione dei requisiti, controllabilità e stabilità del processo, qualità del prodotto,... Una visione ideologicamente distorta perché appunto non esistono pallottole d'argento per far fuori i licantropi e ogni pretesa universalistica non tiene conto della complessità intrinsica del software (essential difficulties) ben argomentata da Brooks.
Altra perplessità è il soggiacente oscuramento del design for change che a mio avviso porta ad architetture sotto-ingegnerizzate e alla fine - a causa di tutti gli adattamenti - fragili e poco flessibili (mentre un'architettura è l'intelaiatura portante di un sistema entro cui far crescere i requisiti).
Anziché elencare altre perplessità termino evidenziando alcuni punti di forza della metodologia del signor Beck: un merito è quello di aver portato in superficie il fatto che il codice di un sistema è il fine ultimo di ogni processo e dunque a questo bisogna dedicare molta attenzione (e aggiungo una buona attività up-front di analisi/design è ancora più determinante); molte volte i programmatori sono avviliti a causa dell'ingente burocrazia che generalmente circonda l'attività di sviluppo e in questo XP offre buoni spunti risolutivi.

La mia idea è che un buon professionista non dovrebbe sposare questa o quella metodologia ma essere capace di fondere il meglio delle proprie conoscenze (e tra queste senz'altro le metodologie agili) nei contesti in cui si trova ad operare.

Linguaggi di programmazione: opportunità o alternative?

I linguaggi di programmazione nascono per svariati motivi tutti rivolti a coprire specifiche esigenze e/o mancanze/inefficienze esistenti.
Pluralità di linguaggi significa dunque maggiore copertura e maggiore sicurezza per i professionisti IT.
Negli ultimi tempi la somiglianza tra Java, C# e C++ è andata aumentando. Come sempre ci sono i puristi delusi dalla Sun (che pensa giustamente a fare $oldi cercando di portare sulla propria barca anche i #isti. Fa bene, ma non so se questo avverrà su grande scala) e i pragmatici che vantano una certa capacità di switching tra le varie tecnologie.
La verità non è mai nel mezzo e di fatti anche in questo caso bisogna scendere un pò in "cantina", per vedere il problema più da vicino.

Punto primo. Limitandoci ai soli linguaggi citati, pare che Java e C# tendano a C++. E' singolare per Java che è nato come antagonista di C++ ("eliminando tutta quella roba inutile", quante volte ho sentito questo insulso commento) ora si trovi addirittura ad introdurre i Generics (certo con tutti i distinguo del caso. Ad ogni modo i Generics hanno una loro legittimità e utilità)
Punto secondo. Se da un lato la somiglianza e dunque l'interascambio di developers tra i vari linguaggi produce sinergia (parola che inebria qualsiasi manager...) non capisco perché allora inventarne o - ancora peggio - impararne tanti.
Punto terzo. Dov'è lo specifico di ogni linguaggio se tutti tendono prima o poi a unificarsi a certi standard? E' nel marketing, parafrasando McLuhan dico: il marketing è il linguaggio (!!!)
Punto quarto. Si ha come il sospetto che la Sun abbia operato in questo modo: Java è senz'altro un buon linguaggio, ben accessibile ai più, con un sacco di buone cosucce che messe insieme fanno un prodotto vendibile. Boom! In pochi anni la Sun è diventata una delle major sul mercato (vendevano hardware. Ora stravendono...non vi dice nulla tutto questo con la strategia dell'Open Source?) con una larga fidelity tra gli adepti e una schiera di evangelist (questa degli evangelist è una cosa che mi fa ridere di brutto) che seguitano a fare il loro bravo predicozzo. Tié! becchiamoci i generics, i foreach, i varargs,...e tante altre cose che NON sono "inutile roba" anzi necessaria per una buona copertura di business (e che non potevano darci - loro, gli evangelist - con la bottiglina perché altrimenti -secondo loro- avremmo avuto un rigetto. Tradotto: avrebbero rischiato un clamoroso fiasco).
Non so se è stata una lungimirante strategia o semplice fiuto di mercato, di fatti ora il linguaggio inizia a diventare più serio e complesso (al di là della complessità intrinseca del paradigma ad oggetti) e fatto salvo alcune eccezioni, le reazioni si sono limitate a innocui e scontati mugugni.
P.S
Scontatissimo il mio rifiuto a dare contributi (?) nelle inutili e infeconde discussioni che ruotano intorno al già eterno quesito: "meglio Java o C#" et similia.

Il paradigma ad oggetti

Rileggo volentieri l'intervista che Alexander A. Stepanov rilasciò a Computer Programming nel 1997 (e scaricabile da qui).
Non entrerò nello specifico delle accuse mosse alla programmazione ad oggetti (critiche rispendite con mestiere al mittente da Carlo Pescio sempre su Computer Programming), voglio solo segnalarvi un sito (OOP criticism) che in ogni caso può aiutare a riflettere soprattutto coloro che ideologicamente abbracciano un paradigma fino a diventarne kamikaze...il sito in ogni caso pare lo sfogatoio di qualcuno "che si e' scottato con l'OOP e ha dedotto che deve essere l'OOP ad essere sbagliata".

Uno dei miti dell'OO (ma fortunatamente sento sempre più gente demitizzata) è che la programmazione ad oggetti (in senso generale) sia la più semplice a modellare la realtà.
Un debunk del mito deve necessariamente partire da un assioma: gli oggetti dell'OO non "sono là, pronti per essere presi"(Bertrand Meyer). Gli oggetti della OOP raramente sono dedotti in maniera automatica osservando il dominio in esame, piuttosto ne rappresentano un modello (alla pari del metodo scientifico che elabora modelli sulla base dell'osservazione) ed è la bontà di questo modello che misura la qualità del paradigma.
In generale credo che difficilmente una mente umana sia naturalmente incline all'OOP, tanto che mi trovo su tutt'altre posizioni con chi ritiene che "imparare da zero l'OOP sia senz'altro preferibile".
La verità, dal mio piccolo punto di vista, è che l'OOP sia maledettamente difficile anche se la si presenta spesso (complice molta letteratura...) come il modo più naturale di progettare sistemi software.
E' uno strumento formidabile e molto profondo, e non si arriva a dominarlo in un giro di pochi anni.

IT-Communism

A dimostrazione di come il comunismo sia un sistema mentale, un modello di pensiero-operativo talmente pervasivo, vi propongo un assaggio richiamando qualche principio e relativa applicazione nel cosidetto mondo dell'IT.

Negazione della proprietà privata. E qui il discorso non può che partire dal movimento dell'Open Source. Ben inteso, credo che ci siano realmente cose buone frutto di questo movimento, ma qui mi preme sottolinearne la natura "filosofica", i motivi "penultimi" che soggiacciono a tale orientamento. Open Source spingendo il pedale sulla "comunione" del bene software, crea i presupposti (ma forse è più giusto dire che è coerente con le sue premesse) per negare -seppur implicitamente- il diritto di proprietà del proprio lavoro e del suo relativo compenso. La realtà poi sappiamo che è ben altro (magari da riprendere in un prossimo post) visto che senza guadagno non vi è economia e senza economia non esisterebbero neppure i fautori del suo affossamento...
Lo stato come principio e norma. Mutatis mutandis tutte le discipline aziendali hanno come substrato la convinzione che innanzitutto i processi debbono essere formalmente rigorosi e pedissequamente applicati per far produrre alle persone buoni risultati. La verità mi sembra di segno contrario: buone persone e poi un buon processo che consenta loro di lavorare. Il processo è strumento non fine e dunque non cado nell'ingenuo errore di pensare che le persone debbano autogestirsi per meglio esprimere la propria capacità/creatività (ricordavo che Booch avesse detto qualcosa sull'argomento e poi l'ho trovato:"Good people with a good process will outperform good people with no process, every time." Propongo questa variante: "Good people with a mediocre process will still outperform a mediocre group of people with a good process").
Il sol dell'avvenire. Quindi il software dell'avvenire...quanti tool, discipline, certificazioni, aziende, consulenti, metodologie, linguaggi, promettono di sistemare definitivamente la faccenda del software bacato o comunque di dominarlo definitivamente? Non esiste la perfezione ma esistono cose (software) perfettibili.

Mi fermo qui ma l'argomento stuzzica ancora molte riflessioni (e spero serene reazioni).

Team...lifting

Qualche mese fa sono stato intervistato da una giornalista inglese con a tema l'ambiente lavorativo e la sua importanza. Titolo: a great place to work.
Quando si parla di successi nel nostro campo tutti inclini a menare vanto per i risultati conseguiti che avrebbero la loro radice nel mitizzato teamworking. Anch'io in quell'intervista sottolineavo questo aspetto (di massima importanza ma che andrebbe riformulato con più precisione...) ma in questa sede mi preme di più chiarirne un altro e cioè perché si registrano sempre tensioni e conflitti in un gruppo di lavoro.
Non faccio disamine sociologiche, mi limito ad osservare che:

• L'eterogeneità del gruppo da molti salutata come valore in sé si è rivelata invece una bella gatta da pelare.
• Quando presente, la gerarchia del gruppo (dal management al programmatore) è assolutamente priva di inter-mediazione e alla fine si finisce per fare ciò che vuole il capo (che molte volte è giusto ma tradotto con forza sulle teste delle persone è fonte di tensione e disaffezionamento), che ha i suoi obiettivi e che qualcuno dovrebbe modulare tenendo presente i sotto-obiettivi di ognuno.
• Senza un leader ne emergeranno molti e a durata limitata
• Fattori ineliminabili (o quasi...) come l'invidia, l'insofferenza e la spocchia giocano e giocheranno sempre un ruolo determinante in ogni forma di collaborazioni a distanze ravvicinata

Vi sono molti modi per gestire un gruppo di persone, e qualche suggerimento era implicitamente presente nei punti sopra esposti.

Resta in ogni caso un solo fattore determinante, irriducibile e pre-esistente ad ogni corso e tipo di esperienza: il valore delle persone e la possibilità di essere guidate da un capo umanamente all'altezza.

Mirabìlia

Report Card
Con ansia non trattenuta finalmente assistiamo alla presentazione (con tanto di demo sul campo) di un mirabolante prodotto (direi quasi messianico) che nell'ordine promette (che noia, la solita solfa condita da contorni secondari spacciati per novità. Ma chi ha detto che le novità sono buone per definizione?):

• Produttività fino al 90% maggiore rispetto ad altri approcci
• Complessità direttamente proporzionale alla semplicità di gestione
• Indipendenza dalla tecnologia: realizzi e alla fine scegli in quale "formato" consegnare: .NET, VB, J2EE, ...(sic!)
• Programmazione in linguaggio naturale! (sic! sic!)
  

...e via delirando.
Evito per educazione di smontare punto per punto tutte le affermazioni ascoltate in due ore comunque trascorse con interesse e non completamente perse (nonostante...)

Nil est dictu facilius.

Certificazione professionale

Ho seriamente iniziato a studiare per l’esame di certificazione Java Architect. Questo mi ha dato modo di approfondire il tema delle certificazioni e a quanti mi pongono la fatidica domanda “ma serve realmente”? o meglio “a chi serve”?, provo a fissare alcuni punti da cui poi far scaturire delle possibili risposte.
Punto primo, il valore soggettivo. Quanto realmente vale per il singolo una certificazione? Trascurando tutto ciò che ordinariamente si ritiene e/o si afferma sull’argomento, il valore della certificazione dipende soprattutto dalla persona che se ne impadronisce. Sto proprio affermando che le certificazioni (quelle buone, naturalmente) non sono assolute, non innescano nessun automatismo. Personalmente è un’occasione di approfondimento e di riflessione (che poi va oltre l’esame...) su argomenti già sotto il mio dominio. In fondo, certificazione viene da certificare ovvero dichiarare, attestare.
Punto secondo, il valore di mercato. Ammettiamo che si sia ottenuto una buona certificazione e con un reale miglioramento delle proprie conoscenze/capacità. Ci attende una brillante carriera? Companies, managers, headhunters tutti lì proni a spalancarci le loro tasche, i loro interessi, i loro progetti? La realtà è che la regola che guida il nostro lavoro è la competenza e non limitata a quella tecnologica (scopo ideale della certificazione). Come dire, le certificazioni sono solo un potenziale elemento di valore aggiuntivo e solo in determinate circostanze, meglio poter aver sul curriculum referenze ad aziende prestigiose e conosciute.
Ad ogni modo, personalmente durante i momenti di recruiting mi sforzo di misurare l’effettivo valore della persona intervistata (il come questo avvenga è argomento tosto assai...) e non solo i percorsi che l’hanno portato fin lì. So che molti altri la pensano ed operano diversamente, ma tant’è.
Punto terzo, la qualità della certificazione. Un abbaglio grande quanto una casa: constato con dispiacere che molte certificazioni sono letteralmente inutili ed onerose* (più il tempo speso che...). Inutili per qualcuno e utili per altri: il capo che necessita di una percentuale di persone certificate (magari col bollino dietro la nuca...), l’azienda erogatrice che a fine anno deve proiettare l’agognata slide sulla crescita della popolazione certificata su XYZ, l’accesso alle gare, ecc.

Si, è un discorso da riprendere.
*Proverò a dare dei criteri di discernimento nei prossimi interventi sull'argomento

Re-engineering...del cliente!

Bene.
Ho appena terminato un meeting con alcuni miei collaboratori. Il cliente chiede un re-engineering mentre il team di sviluppo continua a "dimenarsi" affinché le persone coinvolte comprendano che si tratta di un mero porting tecnologico, adducendo le seguenti ragioni:

• Re-engineering significa aggiungere valore al business


• Re-engineering è sinonimo di efficacia. Molte soluzioni presenti nel sistema vecchio saranno sostituite o addirittura eliminate.


• Il re-engineering parte dal dominio e non dalla tecnologia


• Il porting è un technology shift, i cui benefici sono maggiormente legati (e limitati) alla tecnologia scelta e non alla capacità di un buon architetto.

L'unica cosa che posso aggiungere è che il re-engineering è un processo che parte dalla testa del cliente/company.