ITDevCon 2009: One approach to rule them all

Ringraziando la simpatica compagine di bit Time per la simpatia e l’accoglienza durante lo svolgimento di ITDevCon 2009, pubblico – stavolta entro i 6 mesi! :) – le slide che hanno accompagnato il mio intervento.

p.s. finalmente il blog è di nuovo up...

November 14 2009 | Eventi | No Comments »

I have a dream! A saccottino dream!

Saccottino fallato

Saccottino fallato

Sai cos’è questo? Un saccottino.

Non sembra, non è esattamente l’immagine familiare che hai del saccottino che forse ha accompagnato la tua infanzia, ma è invero un saccottino. L’ho trovato ieri nel mio pacco e sono rimasto abbastanza sorpreso. Anzi, devo ammettere di aver provato inizialmente un certo sgomento, una certa diffidenza. Farà mica male? Poi ho capito che si trattava solamente di due mezzi saccottini evidentemente sfasati [1] rispetto alla catena di produzione in azione nello stabilimento industriale dove questi due sfortunati saccottini erano in fase di confezionamento .

Poi ho capito anche un’altra cosa. Il mio sgomento trovava le sue radici nella rarità. Non mi era mai successo di comprare saccottini difettosi. Il prodotto esente da difetti nell’industria del saccottino è una rarità. E così in molte, moltissime altre industrie.

Che l’industria del software sia storicamente di tutt’altra qualità è una cosa che percepisco io e percepisci anche tu, anche senza dati oggettivi.

Ecco, tutto il senso dietro a SCRUM, dietro a Extreme Programming, dietro allo sviluppo agile, dietro al Lean Software Development… è proprio questo: lo sforzo di ricerca di un mondo in cui un software difettoso generi lo stesso sgomento di un saccottino sfasato.

[1] Uno sfasamento di mezzo saccottino è, in termini controllistici, uno sfasamento di 90°. Lo scrivo qui un po’ perché amo le note a pie’ di pagina, un po’ perché l’ingegneria dell’automazione è leggermente off topic in questa sede, ma solo leggermente.

August 25 2009 | Base | 2 Comments »

Virtù emergente: continuous integration

Una riflessione snella, senza pretese, un divertissement estivo. Sarò breve, seguimi.

La teoria della complessità ci insegna che comportamenti complessi possono emergere da sistemi costituiti da agenti semplici in relazione tra di loro in virtù di regole semplici. Craig Reynolds può introdurti a questi concetti sul web con spettacolari sciami virtuali.

Bene. Poniamo ora un team soggetto a queste due regole:

  1. ogni sviluppatore – ogni coppia – deve fare commit del codice solo a test verdi sulla sua macchina
  2. ogni sviluppatore – ogni coppia – deve prendersi carico della risoluzione dei conflitti che incontrerà al momento del proprio commit

È evidente che la probabilità di avere conflitti nel codice tende a 1 col passare delle ore; i commit degli altri sviluppatori infatti avranno sempre maggiori possibilità di introdurre linee di codice non integrabili automaticamente con le nostre. Questo dato sommato al fatto che eventuali conflitti su poche righe sono comunque preferibili a conflitti su interi moduli del nostro software fanno sì che ogni sviluppatore sarà quindi fortemente incentivato a fare frequenti commit che, in virtù della prima regola, non violeranno la stabilità della repository. Abbiamo quindi introdotto con queste due semplici regole una delle pratiche più preziose del contesto agile: la continuous integration.

Spesso introdurre pratiche nuove nei team può essere complicato anche quando il vantaggio che ne deriverebbe può essere facilmente dimostrato. Individuare regole molto semplice e deburocratizzanti può essere molto utile ad indurre i giusti comportamenti nel team di sviluppo con una redditività molto elevata, anche – perché no – in termini di morale.

August 07 2009 | Esperti | 1 Comment »

Scrum non basta. E nemmeno XP.

In un saliente post del caro Alessandro Astarita leggo

Per avere successo con Scrum, XP o ogni altra metodologia agile, bisogna fare refactoring. Non è opzionale, è indispensabile.

tratto da un post di Ron Jeffries.

Il refactoring è una pratica essenziale. Essenziale, nel caso la sedimentazione linguistica non lo portasse alla luce immediatamente, significa relativo all’essenza, fondamentale, che è assolutamente necessario.

Assolutamente necessario.

Troppo spesso si parla di agile – buzzword che francamente sto cessando di impiegare – e si pensa di poter garantire evolutività incrementale solo con un po’ di iterazioni buttate in un calendario e delle user story scritte male. Bisogna essere produttivi per un mercato che cambia. Bisogna essere pronti a rispondere agli stimoli.

Il codice deve essere pronto a seguirci. Ovunque.

June 20 2009 | Base | 1 Comment »