Extreme Enthusiasm

Here are my slides for my talk at the Italian Agile Day 2010.

I’m happy about how the presentation turned out. I shared my hour with Carlo Bottiglieri. While I came only recently to realize that html templates are evil and objects rule, Carlo has been doing something like this for years. I expecially liked one thing he said:

These days you often hear people say that TDD is only good for the “domain model”. When I started learning TDD I didn’t know that :-) so I started using it for everything, including user interface, persistence and other infrastructure.

Some people say that they do TDD, but when they start a new project they do something different: choose technology, choose application servers, choose frameworks… TDD is meant to help us make decisions. If we make important decisions before starting with TDD, we lose a great deal of its power.

I’m quoting from memory and paraphrasing. I hope I got the meaning right.

Update: Carlo has published his slides.

Update The video for our session has been published.

Quest’anno il programma dell’Italian Agile Day è più ricco che mai. Vorrei poter seguire tutte le sessioni… e immagino che tutti i partecipanti abbiano questo dilemma. Per questo ho scritto alcune note per orientare chi magari non ha dimestichezza con tutti gli argomenti presenti.

Tipi di sessione

La maggior parte delle sessioni quest’anno sono di tipo frontale; cioè c’è un tizio che parla, gesticola e mostra delle slide sul proiettore, e il pubblico ascolta o al massimo risponde alle domande del tizio.

Ci sono però anche alcune sessioni di stampo più pratico: i famosi workshop. In un workshop il pubblico deve partecipare attivamente. Può essere molto faticoso ma è anche molto interessante. Le sessioni di tipo workshop quest’anno sono:

• Agilità come evoluzione sistemica di Pierluigi,
• Due uomini e una lavagna di Alberto,
• Guelfi versus Ghibellini di Sergio,
• The Dot Game di Alberto e Jacopo.

Il Dot Game è anche un gioco: c’è una lunga tradizione nel mondo Agile di giochi concepiti per imparare. Uno dei primi è stato lo XP Game di Pascal Van Cauwenberghe. Io l’ho organizzato decine di volte; penso che sia molto utile. Per approfondire: iscriviti a questa mailing list.

Alcune delle sessioni sono kata o performance di programmazione dal vivo (ne parlo più avanti.) Nella sessione BDD Live Show gli autori si dicono pronti a ricevere l’input dal pubblico nel caso si incontri un ostacolo imprevisto…

Tema: le soft skill

Molti sono attratti dal mondo Agile per le pratiche tecniche: il TDD, il Continuous Deployment, ecc. Ma le pratiche tecniche non sono sufficienti: il software lo fanno le persone, e le persone sono tutte diverse. Non solo diverse l’una dall’altra, ma anche diverse da un giorno all’altro :-)

Per lavorare bene in team bisogna coltivare le cosiddette soft skill. Le sessioni Note to managers: IT is different, get over it di Andrea Provaglio e la keynote di Paolo Perrotta parleranno del fattore umano nello sviluppo software.

Le sessioni Agilità come evoluzione sistemica di Pierluigi Pugliese, Guelfi versus Ghibellini di Sergio Berisso e The Dot Game di Jacopo Romei e Alberto Brandolini sono centrate su come lavorare in team.

Un tema che corre sotto tutte queste sessioni è che lo sviluppo software non assomiglia per niente alla produzione industriale. Anche parlare di “fabbricare” software è errato, a mio avviso. “Sviluppare”, “fare crescere” sono termini più appropriati. Lo sviluppo software assomiglia molto più al giardinaggio che alla manifattura.

Tema: Lean

Il Lean manufacturing è una corrente di pensiero che nasce e fiorisce in Giappone ed ha consentito alla Toyota di diventare il primo produttore di automobili nel mondo. Non lasciatevi ingannare dai problemi recenti per cui hanno preso in giro la Toyota; è come quando per una volta il primo della classe prende un brutto voto, e tutti gli asini gioiscono! Il pensiero Lean mette al primo posto la creazione di valore per il cliente. Da questo concetto apparentemente semplice nascono potenti conseguenze. (Per inciso, la manifattura occidentale mette al primo posto il profitto e una malintesa “produttività”; e i risultati sono sotto gli occhi di tutti.)

In una fabbrica Lean gli operai sono responsabili del loro modo di lavorare. Sono essi stessi che scrivono il manuale di operazione per le loro postazioni. I manager di una fabbrica Lean passano più tempo negli impianti che nei loro uffici. Al centro del Lean c’è il miglioramento continuo (kaizen). Leggi The Toyota Way per saperne di più.

Non so se da questo brutale sommario si capisce che c’è una profonda affinità fra Lean e Metodi Agili. Anche nei metodi agili il fondamento è la consegna di valore reale per il cliente. Anche nei metodi agili le persone sono l’asset più importante. Anche nei metodi agili si privilegiano la concretezza e lo sporcarsi le mani piuttosto che le gerarchie e le teorie tayloriste.

Uno degli strumenti usati dal Lean è il kanban, che è una maniera di limitare la quantità cose che sono contemporaneamente in lavorazione. Il kanban usato dagli agilisti prende la forma di un tabellone su cui il processo di lavoro viene visualizzato. Recentemente il Kanban (con la K maiuscola) è stato presentato come un metodo per introdurre l’agilismo in azienda. Al contrario di Scrum o XP, che sono in aperta rottura con il modo di lavoro corrente, il Kanban ha un’introduzione più “morbida”. Si inizia analizzando e visualizzando sul tabellone il metodo di lavoro corrente, identificando il “cliente”. Questo è il trampolino per introdurre il miglioramento continuo: si misura e si ottimizza il tempo che ci mette un task a passare attraverso il processo. Il vantaggio è che, almeno in prima istanza, non vengono minacciati gli equilibri esistenti. Leggi Kanban per saperne di più.

Le sessioni IAD dedicate al Lean e al Kanban sono

• Scrumban, a methodology fusion, di Fabio Armani, che ha applicato in azienda una combinazione dei due metodi Scrum e Kanban.
• Complexity vs. Lean (in inglese), di Jurgen Appelo, un consulente che pubblica un blog molto seguito.
• La Lean Startup e il customer development model. In Italia. Di Nicola Junior Vitto. Il “Lean Startup” è un’applicazione dei principi del Lean alla nuova micro-imprenditoria. Leggi il blog di Eric Ries per saperne di più.
• Lean e Kanban: la nuova rivoluzione Agile di Claudio Perrone. Claudio ci racconta la sua esperienza in Irlanda come agente di cambiamento.
• The Dot Game. Una delle teorie affini al Lean è la Teoria dei Vincoli (Theory of Constraints) di Eli Goldratt. Sospetto che questa sessione (che consiste in un gioco) presenterà delle riflessioni legate a questo argomento. (Leggete The Goal, è un libro interessantissimo sia per la forma che per il contenuto.)

Tema: il Test-Driven Development

Il TDD, e la sua variante Behaviour-Driven Development (BDD) sono una pratica tecnica centrale per gli agilisti. Se vogliamo partire a sviluppare senza una fase iniziale di progettazione, e pretendiamo di riuscire a mantenere basso il costo di manutenzione dell’applicazione, dobbiamo essere in grado di progettare l’applicazione strada facendo. Altrimenti rischiamo di produrre il classico gomitolo di spaghetti, e quello che facciamo non è agile ma un becero code-and-fix.

Quindi, per raggiungere gli obiettivi dei Metodi Agili, ci serve una base tecnica solida. Il TDD è la tecnica base che ci permette di progettare l’applicazione in maniera incrementale e di fare evolvere il design. Per approfondire questi temi le sessioni Affiliamo i nostri strumenti: un test driver fatto in casa di Jacopo e The secret art of Agile Javascripting
di Luca.

Uno dei sotto-temi che si è sviluppato negli ultimi anni è quello delle abilità artigianali. Per sviluppare queste abilità, non c’è come la pratica! Così come i musicisti, i chirurghi, i cultori di arti marziali, anche gli sviluppatori possono imparare tantissimo dall’eseguire esercizi in maniera consapevole. La sessione di Roberto e Paolo, The BDD Live Show rientra in questo tema, e anche Code Kata Live di Gabriele, Antonio e Giordano. Se volete vedere all’opera questi artisti marziali del codice, potete vedere alcuni loro exploit su katacasts. Oppure partecipare a una serata in uno XPUG.

Per ora…

Ci sono altre cose che vorrei raccontare; altri temi che emergono quest’anno sono “come introdurre l’Agilità in azienda”, “Come misurare come stiamo andando”, più altri temi tecnologici come Javascript e NoSQL. Tempo permettendo posterò un seguito domani.

I presented “Framework-free web programming” at the Webtech conference yesterday. Here are the slides. There’s enough text in them to make them understandable, I hope. If you understand Italian, that is :-) I will translate them sooner or later.

TDD is about design. It’s not about testing.

Last week an interesting thing happened while I was working with a team. They had been writing a new application with TDD since last June, and they were successful in that the application was nearly ready, on time and on budget. But there was one thing that was worrying them.

They had been following an article on the Model-View-Controller pattern, and had structured their application accordingly. There was a controller for every window, and there was a model too. (It’s not a web application, it’s Swing.) The view object was extremely thin, as it only contained code for constructing and laying out widgets; absolutely no other logic in there. The controller hooked listeners to the appropriate UI widgets.

So everything was OK, no? A clear architecture, a clear separation of concerns, everything tested. There was a problem: the controllers were big objects, with intricate logic. The tests were difficult to read and difficult to write. It was difficult to understand what was being tested. My worry was that maintenance of that GUI could quickly turn into a mess. Also my customer was worried about that. The fact is, whenever anything had to be changed about the logic of that window, the controller would have to be changed, and the view would have to be changed, and the model would have to be changed. We had three big monoliths that were involved in everything. This ran against the open-closed principle.

My first reaction was to call upon my refactoring skills. Take the unreadable tests and make them readable. Use extract method and expressive names to make them read like a story about what was being tested. Some success there, but not a clear victory. It was still difficult to find the code being tested, as those were end-to-end tests. Then I found the bit that contained the important logic and wrote proper unit tests for it. Some success, as I was able to test with precision all the corner cases that the end-to-end test was not exercising. But still not a clear victory. Then I started to work on the big controller. I took the worst one with me in my hotel room, and I spent a chunk of my evening trying to refactor it. Extract method, rename, extract class. Extract, extract, extract. It was still big and ugly. With a bit of polish, but still big and ugly. Still running against the OCP.

The next day I pulled a different set of tools. I remembered the lessons in Francesco Cirillo‘s Emergent Design Workshop. I showed the team how to use Francesco’s technique, which is to start with a design of the communicating objects on the whiteboard. After one day of practice with this technique, we attacked the real problem. We started designing the main application window from scratch.

The team was surprised, and I was surprised as well, because the big controller evaporated. It was clear, when working at the whiteboard, that it was not necessary. The model object evaporated too. We designed the main scenarios, and we saw that a simple design could accommodate all of them. At first I sketched the design for them, but they were soon criticizing my design and changing it to suit their needs and tastes. Then we started coding; it went smoothly because the design was already done, and we were taking advantage of all the low-level objects that they had implemented already.

We learned is that when the design is wrong, no amount of refactoring moves will get you out of the hole.

My next speaking engagements:

• Webtech Italy on November 10. I will speak on a topic dear to my heart, “Framework-free web programming”. Why do we assume any (web) programming job should start by selecting the framework? My opinion is that what you *really* need is an understanding of the fundamental protocols of the web, and an understanding of object-oriented programming.
• Italian Agile Day, November 19. I will speak about “TDD for web views”, or how to apply TDD directly to the GUI of web applications, rather than avoiding it with tricks like Humble Dialog Box, or substituting it with end-to-end Selenium tests.
• XP Days Benelux, November 25. Together with Antonio Carpentieri I will present a workshop on the Open-Closed Principle Dojo. It’s a way to learn an important principle of object-oriented programming.

Hope I will make it through all of this…

Il programma è stato pubblicato (anche se ci saranno piccoli aggiustamenti) e le iscrizioni sono aperte: affrèttati perché sono già spariti quasi 300 dei 400 posti disponibili!!!

I know a developer who says that he enjoys discussion during pair programming. He says that it’s one of the ways to learn and grow on the job.

I disagree. Here’s why. Discussion is waste. In the sense of Lean, discussion is a non-value adding activity. Consider coding and discussing. Do they add value? How do you tell what is waste and what is value-adding, anyway? After all, if you don’t discuss things with the customer and with your collegues, you can’t arrive at a functioning release, right?

David Anderson in his Kanban book explains well, IMHO, how to tell waste from value-adding. Suppose that discussing is value-adding. It that is so, let’s do it to the max! The more, the better. Do the same thought experiment with coding. If coding is value-adding, then let’s do it to the max! Which of the two rings more true?

I have this image in my mind. Consider when you release a feature to the customer. The release is made of lines of code you added, changed or deleted. The value-adding activity was in writing those lines of code. Everything else is waste.

I understand that programming is not typing, and that thinking is the most important activity that happens while we work. Yet, this thinking is waste. Suppose that you can code a feature without much thinking, because (for instance) your team has standard ways of dealing with this sort of features, or you did similar things years ago, and you know how to code a solution. This position is better than the position of someone who does not know how to proceed, and has lots of choices and doubts and has to think.

So if you don’t know how to solve a problem, by all means, think! Step away from the keyboard, consult books, discuss at the whiteboard, ask in forums, look in your codebase to see how this problem was solved before. All these activities are necessary waste. Just don’t charge heads down and try to code yourself out by brute force. That would be probably more wasteful.

You see, not all coding is value adding. Only the coding that produces the lines of codes that will make the release is value adding. Spikes, refactorings, false starts are all (perhaps necessary) waste.

I have not become convinced that iterative development, small steps, refactoring are to be avoided. I’m not advocating doing some big upfront design to make sure we can hit the release code without iterating, without incrementing functionality bit by bit, without refactoring. I still think that iterative and incremental design is the only reliable way to produce good software. But we must remember that refactoring per se is waste. Francesco Cirillo is fond of saying that emergent design is not “doing some messy work now, then I will refactor”. It’s more efficient to write incremental code that can be extended without refactoring; it’s more efficient to exploit the Open-Closed Principle!

Let’s get back to the subject of discussions while coding. My opinion is that programmers either know how to proceed, or they don’t.

• If they don’t, they should do spikes, study, think, stop pretending they are doing a pomodoro of coding and call it a pomodoro of studying.
• If one of the developer thinks he knows how to proceed, he should be the driver, explain to make sure that the navigator understands, and then do it. The navigator’s job is to make sure that the driver has a reasonable understanding of the problem, and he’s not doing something that is probably/obviously/previously shown to be a dead end.
• If both developers have a differing idea, then my friend says they should discuss the relative merit of both points of view and come to an agreement to what to do. I disagree. This is pure waste. I think that it’s more productive to choose one of the two ideas and see how it turns out. That is worth more than all the discussion in the world. Choose quickly; challenge the other saying things like “I bet I can solve it cleanly in 4 pomodori!”.

The navigator’s job is still to support the driver, not to challenge the driver’s idea. That would take energy away from both. If the navigator thinks that the driver’s idea might work, he or she should support the driver and accept that the thing will be done differently. Now this will help both grow and learn, more than discussing. Just remember to respect the other, and always explain clearly what your idea is.

Summary: my friend Federico Gobbo argues about the wisdom of pushing hard for Italian citizens to learn English.

Segnalo questo post del mio amico Federico Gobbo, che affronta l’argomento dell’insegnamento della lingua inglese, e di come, quanto e come sia saggio spingere in quella direzione.

I’m reading The Toyota Way by Jeffrey K. Liker. It’s changing my mind.

When I started this book, I thought, well, this book is a compilation of interviews and stories, so there is no real meat, it’s not really teaching the methods they are using in Toyota. I thought it was a pretty fluffy book. Was I wrong!

It’s true that the meat of the book are stories that the author experienced himself, or were related to him. It’s not true that there are no practical hints on how to apply Lean Production; there are many examples of how to do that. But that’s not the point. I mean, Toyota makes cars, I make software. The actual practices are meant to solve their particular problem. What this book shows is how getting good at management comes from a shift in the way you think. The wealth of examples in the book pushes the reader to a different way of thinking.

The Toyota Way is also a depressing book. Perhaps half the stories in the book are about how American companies tried to apply The Toyota Way and failed miserably. This speaks about the importance of being serious in what you do. The Toyota people are dead serious. Which is not to say they don’t have fun… If your idea of fun is to stretch your capabilities to the limit, keep learning and getting better.

There is another feeling that comes to me while reading. The Toyota company is what in Italy is called “primo della classe”. This expression means “the boy or girl with the best grades in their class”, and carries a negative connotation. This says a lot about the way people thinks in Italy; the idea that someone can be better than me, or maybe *a lot* better than me is met with hostility. Our thinking is, “they are first because they spend countless hours on the books; if I did that I would get the same grades, but I won’t bother”. Ha! Do I have what it takes to really spend this effort? I probably don’t.

So these Toyota people come across as “primi della classe” because they are really good. And there are companies out there that are way better than the norm, and still are not as good as Toyota; which shows that there is a long path of improvement. This realization can be either exciting or depressing; it’s our choice :-)

As I keep reading the book, it takes me a lot of time as I’m taking notes, and all the while I think how the principles of the Toyota Way would apply in my situation. For instance, the book says that Taiichi Ohno insisted that when you walk to a plant, you should see immediately if everything is OK, or there are problems.

Translate that to software development. How would you do that? Good question! Agile developers do many things to make the development process visible; the cardwall, the burndown chart, the velocity chart are good visual indicators. But can we do better? Translate “plant” to “a workstation with a pair of programmers at work”. Can you see that their work is processing smoothly? One valuable insight is recognizing that the pair might block on a problem, just like an assembly line can jam. How do you see when a pair is blocked? (Hint.) What do you do when a pair is blocked? Do you treat this block as seriously as you would for a defect in the product? Do you try to understand the root cause of the block, so that it doesn’t happen again? Do you measure how many such “incidents” happen in a week? Do you measure how much time is spent working smoothly, and how much time is spent blocked on a problem?

One day I was discussing with Josh (not his real name) a problem we have with the customer. The problem is a very common one: priorities keep changing, every day we receive new “urgent” tasks, we have lots of work-in-progress, and it’s difficult to get the customer to approve or give feedback on what we did.

Josh did not agree with me on the nature of the problem. He said that he respects our customer as Product Owner; he accepts the priorities, and any new task they give us is properly recorded in the backlog. But Josh, I said, I’m afraid that the day-to-day priorities they give us are not what the customer really needs. The boss of the person that gives us priorities may not be happy with the results we are getting. Josh replied, “if what we do is not what their boss wants, then let it be. It will come up at some point.”

What is Josh thinking? It may be that his reasoning is “it’s not the best course of action for us to rock the boat with their boss; your worries might be wrong, perhaps the priorities are right after all. And if you are right and the priorities are wrong, well, the best course of action is to let this problem emerge.” That’s my best interpretation of what Josh thinks.

The other interpretation is that Josh is delegating responsibility to the customer’s product owner. If the PO gets priorities wrong, we’ll fail, but it will not be our fault. It’s another way to say “You just tell me what I have to do and then I do it”. This goes against the principle of taking responsibility for the outcome of a project. The reasoning is that if the project fails, we can show that we did all that was required of us. But being “right” in a failing project is not a great outcome.

What’s my conclusion? I found two interpretations for Josh’s reaction. They are both valuable; I resolved to talk to Josh further, to see if there is anything else behind his words. And I resolved to discuss the issue of priorities with the POs.