Notizie da Matteo

Le prossime iniziative

Prossime iniziative

15 ottobre, Firenze: partecipo al workshop di Dan North Accelerated Agile: from Months to Minutes. Dan North è un pensatore controcorrente, che ha l’abitudine di ri-pensare le idee consolidate e farle crescere; come ha fatto inventando il “Behaviour-Driven Development”.

20 ottobre, Milano: presento uno Scrum Workshop al Talent Garden. Una mezza giornata in cui impareremo i principi di Scrum giocando. Questa simulazione di Scrum è stata inventata da Giulio Roggero. Non è necessario saper programmare, ma l’esperienza con il Lego può essere utile!

22 ottobre, Milano: presento il workshop You keep talking about Value, but I do not think it means what you think it Means presso il Milano Extreme Programming User Group.  Questa è una versione di prova per questo laboratorio che presenterò in novembre all’Italian Agile Day e agli XP Days Benelux. Vedi più sotto la descrizione.

23 ottobre, Giussago (PV): altro test run di You keep talking about Value, but I do not think it means what you think it Means, stavolta presso il Pavia Extreme Programming User Group.

4 novembre, Bologna: presento il corso Test-Driven Development per lo sviluppo su Android. Sviluppare su Android è facile e divertente… all’inizio. In questo corso impariamo alcune tecniche per mantenere l’impeto e il divertimento nel lungo periodo, per continuare a fare crescere le tue applicazioni Android senza paura e senza problemi.

12 novembre, Bologna: presento la sessione “Parlare Java come un nativo: come uscire dal punto di vista procedurale ed ottenere i benefici della programmazione ad oggetti” ad un convegno organizzato dall’ASSI. Torneremo alle basi e parleremo del perché la programmazione ad oggetti sia importantissima e perché sia così difficile adottarla nel mondo del software gestionale.

14-15 novembre, Ancona: si svolge l’undicesimo Italian Agile Day: questo è il principale convegno del mondo Agile in Italia. Presenterò una sessione: Perché è così difficile fare Extreme Programming. Parlerò di come mai non sempre si riesce a migliorare e svelerò i motivi per cui anche se la maniera di ottenere software eccellente e a buon mercato è ben nota, sono pochissime le organizzazioni che se ne avvantaggiano.

Sempre all’Italian Agile Day, presenterò anche un workshop intitolato You keep talking about Value, but I do not think it means what you think it Means.  Irequisiti sono il punto debole di tutti i progetti software. E non c’è da stupirsi: i principi dell’ingegneria dei requisiti sono ignoti ai più. In questo laboratorio impareremo alcune tecniche fondamentali per distinguere i veri requisiti dalle idee di design, e per esprimere requisiti vaghi come “user friendly” in maniera precisa e verificabile.  Tutto ciò grazie alle cose che ho imparato nei corsi di Tom e Kai Gilb.

27-28 novembre, Eindhoven (NL): si svolgono gli XP Days Benelux.  Presento il workshop You keep talking about Value, but I do not think it means what you think it Means insieme ad Antonio Carpentieri.  Questa è la dodicesima edizione della migliore conferenza agile a cui abbia partecipato.

Febbraio 2015, Giussago (PV): 7pixel sta organizzando insieme a me e ad Avanscoperta una Scuola di Extreme Programming. Durerà una settimana e impareremo le tecniche fondamentali che servono a un programmatore per avere successo con i Metodi Agili. Per non dire che sono anche le cose date per scontate dai datori di lavoro a Londra e a Berlino…


xpmatteo essentials

Alcune presentazioni passate:

  • The Unix Way vs. The Java Enterprise Way, presentato a Incontro Devops Italia 2014 (infodeck)
  • L’arte perduta di pensare a oggetti, Codemotion 2012 (video , slides)
  • Pianificazione, pattern e antipattern, Better Software 2011 (video, slides)
  • Responsive Design e Analisi XP, Codemotion 2012 (video, slides)

 

Is Test-Driven Development dead?

C’è stata molta discussione quest’estate su un post di David Heinemeier Hansson, il creatore di Ruby on Rails, che è il web framework di maggiore influenza di sempre.  David ha osservato che con il TDD, lui non riesce a ottenere buoni risultati.  Di più: ha osservato che i programmatori Rails che cercano di applicare il TDD nel loro lavoro finiscono per peggiorare il loro design.  David lo chiama “test-induced design damage”!

Eppure i proponenti del TDD, come me, sostengono che il TDD è una tecnica di programmazione importantissima, che tutti i programmatori dovrebbero conoscere ed applicare.  Chi ha ragione?

Secondo me bisogna capire le premesse del dibattito.  David Heinemeier Hansson, che è una persona intelligentissima, ha inventato un framework in cui il punto forse più importante è che ad ogni classe corrisponde una tabella di database, e ad ogni colonna della tabella corrisponde un’attributo della classe.  Questo risolve l’annoso problema dei programmatori che sono spesso costretti a scrivere codice orrendamente ripetitivo solo per trasferire i dati dal database agli oggetti e viceversa.

Tutto vero! Con Rails il codice ripetitivo sparisce, e l’accesso ai dati è quasi trasparente.  Ma c’è un grosso MA: così facendo, abbiamo legato rigidamente, mani e piedi le nostre classi alla struttura del database.  Questo rende estremamente difficile non solo fare TDD, ma anche fare Object-Oriented Programming.  Per chi voglia fare TDD e OOP, è molto importante essere in grado di disaccoppiare gli oggetti dalle tabelle.  Con Rails abbiamo proprio l’opposto, un fortissimo accoppiamento.

E allora, chi ha ragione?

Tutti e nessuno.  Rails e OOP sono materiali che hanno differenti proprietà (questa è la metafora dell’ottimo Carlo Pescio).  Un bravo costruttore conosce le proprietà dei materiali e sa quando conviene usarne uno e quando conviene usare l’altro.  L’importante è rendersi conto di quello che si sta facendo.

I punti di forza di Rails sono l’immediatezza, la rapidità e la consistenza con cui si può realizzare un’applicazione web di qualità.  È il materiale ideale per chi sforna molte applicazioni il cui sviluppo dura uno o due mesi.  Il punto debole è che queste applicazioni soffrono il tempo e la complessità.  La maggior parte degli sviluppatori Rails si trova in difficoltà quando il problema comporta logiche complesse, da aggiornare e manutenere negli anni.

I punti di forza dell’OOP sono l’opposto di quelli di Rails: ci vuole più tempo (e anche più esperienza e capacità) per programmare ad oggetti bene.  In compenso, non c’è nulla che sia meglio degli oggetti per risolvere problemi complessi, pieni di eccezioni, casi speciali e logiche non uniformi, che devono evolvere negli anni e che sono alla base della ricchezza di un’azienda.  Insomma, per le applicazioni che sono realmente “enterprise”.


Letture

The Toyota Kata di Mike Rother.  Questo libro è il migliore che abbia letto finora sulla cultura lean di Toyota. Mi ha fatto capire molte cose su che cosa significa perseguire il miglioramento continuo, su come rispondere quando ci accusano di essere dei “talebani” dei Metodi Agili, su come fare mentoring in maniera efficace.

The Checklist Manifesto di Atul Gawande. L’umile checklist è uno strumento che permette ai piloti di aviazione di comportarsi in maniera consistente ed efficace in situazioni complesse e difficili.  Gawande spiega come le checklist abbiano consistentemente ridotto le complicazioni in chirurgia ed accenna a simili risultati riportati nel campo degli investimenti.  Possibile che le checklist siano utili anche nello sviluppo software?  Mi piace la conclusione su come la disciplina e l’addestramento siano molto più efficaci dell’eroismo.