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.

Leadership

Non so come si diventa leader. Posso solo dire che osservandone uno vero si registrano le seguenti dinamiche:

• E' circondato da persone che generalmente comprendono in anticipo le sue richieste
• Le persone reputano un arricchimento seguirlo
• L'autorità è riconosciuta coralmente (o quasi...) e non per imposizione
• Le persone si sentono considerate anche al di là degli interessi contingenti

...e le seguenti capacità:

• tende a valorizzare ogni persona secondo le proprie caratteristiche
• lavora duro, non si inchioda in meeting inutili o fogli excel super-decorati
• delega ma non per incompetenza o peggio per de-responsabilizzarsi
• non fa scenate
• sa controllare la sua invidia (l'invidia è quasi ineliminabile dalle ossa di un uomo)
• non confonde il singolo con il gruppo. Il gruppo in ultima analisi è solo una astrazione, meglio parlare di collaboratori
• è competente, riesce con naturalezza a passare dalla big picture ai problemi contingenti
• è uno scudo per il team e una freccia per il cliente

E poi leader un po' anche si nasce...altrimenti si assume che è solo una technicality da apprendere (gli americani in questo fanno davvero ridere :-))

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.

Apertura

L'unico intento di questo blog è quello di esprimere opinioni personali in merito al mondo dell'Information Technology.
Nessun riferimento ad aziende, prodotti o altro apparirà in queste pagine.
Buona lettura.