Archivi categoria: software engineering

L’illusione del controllo

Lo stile da pubblicità comparativa, inaugurato nel software design dal Manifesto Agile (è meglio X rispetto a Y, è meglio W rispetto a Z, …) è ancora attuale.

Un uso recente in I Prefer This Over That di Elizabeth Endrickson:

I prefer:

  • – Recovery over Perfection
  • – Predictability over Commitment
  • – Safety Nets over Change Control
  • – Collaboration over Handoffs

Endrickson spiega che la realtà dello sviluppo, del rilascio e dell’uso dei prodotti è sempre più dinamica di quanto pensiamo, anche quando ci illudiamo di controllarla tramite processi ben definiti e che riteniamo affidabili. Le sorprese sono comunque dietro l’angolo.

“When we design processes that attempt to corral reality into a neat little box, we set ourselves up for failure. Such systems are brittle. We may feel in control, but it’s an illusion. The real world is not constrained by our imagined boundaries. There are surprises just around the corner.

We can’t control the surprises. But we can be ready for them.”

Miglioramento: processo o strumenti?

Come migliorare lo sviluppo software? Con strumenti migliori? O rivedendo il proprio processo di sviluppo?

Molti sostengono che partire dagli strumenti è una scelta perdente: prima bisogna definire un processo adeguato, e solo in seguito passare alla scelta degli strumenti. Affermazione di buon senso, messa però in discussione da un articolo di Jitka e Michael West: “Through These Fields of Destruction: The Tools Versus Process Wars”, contenuta nel numero monografico di Crosstalk dedicato al rapporto tra tecnologie e processi. Secondo gli autori, è meglio se la definizione di processo e strumenti viene pensata insieme.

CrossTalk è il bimestrale online e gratuito sul software engineering pubblicato dalle organizzazioni militari USA.

Intervista a Grady Booch su UML

InfoQ ha pubblicato un’intervista a Grady Booch, uno dei principali autori di UML (Unified Modeling Language – la notazione standard per rappresentare i sistemi software).

L’intervista tocca vari temi, tra cui lo sviluppo iterativo e agile, UP, XP, Scrum, linguaggi di programmazione – ma buona parte è dedicata a UML, alla sua diffusione, ai suoi vantaggi e limiti, alla sua evoluzione nel corso dei due decenni trascorsi dall’idea iniziale a oggi.

Tra le osservazioni di Booch, il fatto che il 20% di UML è sufficiente nell’80% dei casi; che la diffusione di UML non ha mai superato il 20% delle realtà che sviluppano software (a parte il mondo real time, dove le percentuali sono superiori); che l’uso di UML come linguaggio di programmazione è molto diverso da ciò che i suoi autori intendevano.

Per i curiosi, può essere interessante confrontare l’intervista del 2014 con le risposte che mi diede nel 1998, poco dopo la pubblicazione di UML.

Agile! (secondo Bertrand Meyer)

Bertrand Meyer ha fornito, con “Agile!“, un’analisi esauriente dei metodi agili per lo sviluppo software. Un raro esempio di serio esercizio critico nell’ambito del software engineering.

Nella tradizione della miglior critica artistica o letteraria, il libro esamina in profondità alcuni tra gli approcci agili più noti (Scrum, eXtreme Programming, Crystal, Lean) evidenziandone i punti di forza e le mancanze, in uno stile arguto e spesso divertente.

Come per ogni serio esercizio di critica possiamo essere o meno d’accordo con i singoli giudizi espressi dall’autore: secondo me, ad esempio, il “lavorare ad un ritmo sostenibile” ed i “gruppi di lavoro multi-funzionali” sono pratiche generalmente efficaci, non pratiche a cui viene dato un risalto eccessivo da parte degli approcci agili.

Ma ogni esercizio di critica comporta prese di posizione discutibili, se non si vuole restare nel vago e nel generico, e questo libro di Meyer è un servizio davvero utile per il mondo dello sviluppo software.

 

Alta maturità organizzativa

Numero monografico di Luglio / Agosto 2014 di Crosstalk (The Journal of Defense Software Engineering, cioè lo sviluppo software per il Dipartimento della Difesa USA), su “High Maturity Organizational Characteristics“.

Tra gli altri, interventi di Gerald Weinberg sulla qualità dei sistemi, di Alistair Cockburn su Disciplined Learning, di Capers Jones su come arrivare all’eccellenza in ambito software.

Particolarmente interessante la presentazione dell'”Incremental Commitment Spiral Model”, una riformulazione del modello di sviluppo a spirale a cura di Barry Boehm (ideatore del modello a spirale originario) ed altri autori.

Architetture a microservizi

Un paio di articoli recenti sullo sviluppo di applicazioni basato su servizi distribuiti.

Microservices“, di James Lewis e Martin Fowler, descrive le caratteristiche più rilevanti delle applicazioni a microservizi, le relazioni con la Service Oriented Architecture (SOA), gli aspetti organizzativi (come la necessità di non avere responsabilità distinte per sviluppo e manutenzione), gli aspetti relativi ai metodi di progettazione (ad esempio il fatto di definire i servizi basandosi su “oggetti di business” disaccoppiati, e la maggiore difficoltà di effettuare interventi di refactoring).

Fowler è poi tornato sull’argomento in “Microservices and the First Law of Distributed Objects” (dove la prima legge è “non distribuite i vostri oggetti”…), evidenziando in modo più preciso le differenze tra lo stile di sviluppo centralizzato e quello distribuito nella progettazione delle interazioni tra componenti.

Elogio del dubbio metodologico

In passato si basava lo sviluppo software sul credo che, operando in modo disciplinato, si potessero generare requisiti perfetti all’inizio del progetto…

“The old days of software development were grounded in a belief that discipline could generate perfect up-front requirements — a belief that perhaps emerged from the hope that such reasoning could eventually be fully automated, but that good human effort was an adequate substitute in the mean time. Methodology — another one of the truths that was a product of that culture — was held to be enough to achieve success. If we ever failed to deliver, we blamed ourselves […]. No one dared question the methodology itself.”

James Coplien, in Methodical Doubt, sostiene che ciò che assumiamo come verità deve essere dimostrato sul campo, e potrebbe cambiare nel corso del tempo. Anche nel mondo del software.

La crisi del software è discutibile

Una ricerca spesso citata sullo sviluppo software è il Chaos Report, pubblicato periodicamente a partire dal 1994 dallo Standish Group. Il Chaos Report classifica i progetti in tre categorie: successo (risultati coerenti con i requisiti iniziali, forniti nei tempi e con le risorse previsti); discutibili (risultati inferiori alle attese e/o tempi e/o costi maggiori); fallimenti.

I dati del Chaos Report si possono interpretare in diversi modi: una critica ragionevole in questo articolo di Scott Ambler sul Dr. Dobb’s Journal: The Non-Existent Software Crisis:  Debunking the Chaos Report.