Danilo Sato

The second day of the conference was one of the busiest for me, and it started with a great keynote…

Keynote: Leveraging Diversity in Parallel: Perspective, Heuristics and Oracles – Scott Page

Scott Page, author of “Complex Adaptive Systems: an introduction to computational models of social life” and “The Difference: how the power of diversity creates better groups, firms, schools, and societies”, gave the introductory keynote on the topic of diversity. His talk was one of the most interesting of the conference to me, since he showed the “algebra of collaboration” or, in other words, what are the factors that make diversity work in a team. A few of the highlights for me were:

• The importance of bringing different perspectives to the table: his example of playing the card game “Sum to 15″ as Tic-Tac-Toe was really good.
• When it comes to problem solving, hardness is not the same as complexity: in hard problems, the solution space have lots of peaks (hard to find the global optimum); in complex problems, the solution space moves (even if an optimum is found now, the entire landscape might change due to external conditions).
• I’ve read about the Wisdom of Crowds before and saw James Surowiecki’s keynote at Agile 2008, but Scott showed the formula behind it: crowd error = average error – diversity. In other words, the amount of diversity will decrease the average error of a crowd.
• Netflix Prize: an amazing story about a three-year-long contest put up by Netflix to beat on their own algorithm that predicts how much someone is going to enjoy a movie based on their preferences. What started as a competition to come up with the best algorithm, ended up in a race to collaboration, when the teams running for the prize started combining their approaches and finding that the diversity on the combined algorithm would yield a better result than any of the solutions in isolation. You can read more about this story here.

“Diversity becomes more valuable as the problem becomes harder and harder” — Scott Page

Thawing the “Design Winter” – Michael Feathers

The second talk I attended in the morning was about how there’s not much going on in the software design space lately. Michael Faethers started off noting that our industry is very generational: a lot of the innovation on development techniques in the past, were followed by a wave of design books around the topic (Structured programming, then Structured Analysis and Design; Object-Orientation, then OO Analysis and Design; and so on). Michael said he decided to stop when he saw the book “Aspect Oriented Programming with Use Cases” :-) But with Agile techniques, the last good reference about design was Martin Fowler’s “Is Design Dead?”, from the early 2000’s. Some of Michael’s points on the topic were:

• Design happens around constraints: everytime there are decisions to be made around how to develop a given piece of software, there will be design happening.
• Architecture is design: people should acknowledge that and recognise software architecture as design.
• Look at design as the composition of “things”, not just classes.
• Design are the trade-offs and the discussions you make when taking a particular decision.

I found it an interesting take on the topic, and agree with most of his claims about software design. I personally think that, as a TDD practitioner, I spend a lot of the time doing design (coding is a design activity, not just typing). I also agree that we need to think about design in a higher level, when defining the system/application architecture: those are the decisions that will be hard to change. To me it’s about being able to combine those early-and-hard-to-make decisions with the emergent aspects that you will discover with time, as your system evolve. What you can’t expect is to get it right on the first time, but be flexible enough to incorporate your learnings into something that can evolve.

The Five Habits of Successful Lean Development – Mary Poppendieck

This was the only session I ended up attending on the topic of Lean/Kanban on this conference. Mary summarised 5 habits of successful lean teams:

• Purpose – “Why are you doing it?” In lean companies, workers have a high sense of purpose and understand how their jobs relate to the common goal/vision of the company.
• Passion – “We Care” Having individuals with intrinsic motivation will produce high quality results.
• Professionalism – “Build the right thing” customers don’t want software. If they could get the same thing without software, they would go there. But also “Build the thing right” as simple as possible – and no simpler
• Pride – Expect local decisions, and push them to the front-line workers. They are effectively engaged in delivering superior customer outcomes.
• Profit – “GM stays in business to make money. Toyota makes money to stay in business.”

As catchy as it sounds to summarise Lean into these “5 Ps” mnemonics, I found it to be just a partial view into the topic. Other strong aspects of Lean are the focus on people, and on leaders taking an active role as teachers. These were some of the things I would also expect to see in a lean organisation that I found missing on this “5 Ps” view.

Done Considered Harmful – Marcus Ahnve

This was a lightning talk by my friend Marcus, and I found it really interesting. It was provocative, by picking on a widely discussed concept in Scrum: the Definition of Done (and things like Done-Done, or Ready-Ready). Marcus’ point is that by calling it “Done”, it creates a fake state that usually translates to a hand-off to a different team, or a partial completion state that encourages local optimization. From Lean thinking we know that hand-offs are usually a big source of waste (along with the queues that are usually associated with it).

I was worried he would only present the problem in the talk, but was otherwise pleased with the approach he suggests to tackle this problem: instead of “Done”, call the state by what it represents (e.g. “Ready for deployment”, “In UAT”, “In Production”). Look at the last column in your wall from a hand-off perspective and treat it as inventory in the end-to-end value stream: you might be accumulating WIP and optimizing locally instead of improving the overall effectiveness of your value stream.

Test Automation at Enterprise Scale – Mark Streibeck

This was the technical session I most enjoyed in the conference. Mark talked about the story behind creating Google’s infrastructure to run tests in a massive scale, across teams and codebases, and to provide useful feedback and reports to their developers and teams. Some of the highlights for me were:

• Scale of the system: they run 60M tests/day, including browser tests (cross-browser and running multiple configurations). More than 1700 projects use it (they account that ~80% of all tests are run on this system). The system runs in ~5000 cores.
• Sharing their challenges: this project involved a lot of infrastructure work, which took a lot of time at the beginning of the project, to come up with a scalable architecture. Also, they had to design a UI for a system that solves a known problem in a different way. They also had a lot of work when integrating with various heterogeneous build/test systems that were already in place accross different teams.
• Rollout process: the way they planned and executed the rollout across the company: starting with a few “early innovators”, organic rolling our to a few “early adopters”, and using feedback from these early teams to “fix it” when helping the “early majority” (they even had setup a day where the entire software engineering group could fix things to make the system better.)
• Creativity when solving problems: one of the biggest problems on building and running tests was fixing dependencies issues for projects. Instead of tackling the difficult task to try and solve those issues as a system feature, they focused on improving the way that these issues are displayed on the UI. Just showing the dependencies and letting the teams see it and fix it by themselves proved to be a much simpler solution to the problem.

Conference Banquet and Keynote

The second day finished with a keynote and banquet at the Student Society building. The keynote was presented by Bjørn Alterhaug and John PÃ¥l Inderberg, and the topic was “Improvisation: Between Panic and Boredom. Perspectives on teamwork, dialogue and presence in music and other contexts”. It was a very interesting talk about improvisation in music but, most of all, it showed me how practice can lead to mastery: the dynamics between the two musicians and how they communicate to each other through music was a fine example of highly skilled individuals that can achieve incredible results in a highly collaborative environment. A great talk to an Agile audience :-)

The evening finished with an amazing banquet and more music concerts, including a “Keep of Kalessin” show – an Epic Metal norwegian band.

Tuesday was the first day of the XP2010 Conference, being held in beautiful Trondheim, Norway. I was on a morning flight from Oslo and only managed to arrive at the venue in the afternoon. It was nice to see a lot of my friends again – so far, I managed to count 8 Brazilians, which is probably the highest number in XP conferences so far :-)

Functional Programming with XP – Amanda Laucher

The first talk I attended in the afternoon was from my friend Amanda Laucher. She presented on an interesting topic, discussing how Functional Programming languages and concepts can relate to today’s Agile practices and principles. Some of the lessons that I took away from her session were:

• Functional Programming and Testing: she talked about different aspects of Functional Programming and how you can approach testing them. Things like: testing for lazyness, testing monads, minimizing side-effects, testing on strong vs. weak typed languages, testing on static vs. dynamic typed languages (and useful tools like quickcheck). Even though I don’t have a lot of professional experience in FP languages, one particular topic resonated quite strong with my experience: “you need to know FP before you TDD in FP”. On our Coding Dojo in São Paulo, we learned a similar lesson when trying to TDD algorithms: you need to have an idea of how to solve the problem before you drive your solution with TDD. If you don’t know how to solve your problem, TDD won’t give you the solution.
• How to learn a new language: I really liked Amanda’s pragmatic approach to learning new languages. I particularly liked her reference to the Functional Koans, specifically designed to teach you features of a new language by giving you failing tests that you need to understand and fix. This approach separates the learning of the language, from the learning of the testing tool, or TDD. This is a problem I found when trying to learn a new language by first looking for the testing frameworks available, before understanding the languages’ constructs and concepts.

System Metaphor revisited: The lost XP practice – Joshua Kerievsky

My second session of the day was Joshua Kerievsky’s take on the System Metaphor, an XP practice that he asked on his review of Kent Beck’s second edition of the XP book to be removed, and that has been later applied with great success on Industrial Logic’s main product.

He first talked about metaphors in general: how they link a source domain to a target domain, how they’re always partial, and how people need to have experienced the metaphor in the source in order to apply it to the target. He also briefly compared the role of a System Metaphor with the Ubiquitous Language, as described by Eric Evans on Domain-Driven Design (this is something I came across a while ago too). Finally, Joshua described the benefits of a System Metaphor, summarising them on the three I’s:

• Illumination: when the chosen metaphor is good, it will provide illumination into aspects of the system design, clarifying unfamiliar design via a familiar domain. It will help describe not only static structure, but also the runtime behaviour of the system. I particularly liked how he described two ways of understanding the Composite pattern using concepts from the music metaphor.
• Inspiration: a good metaphor will also provide inspiration for new ideas. It provides a system of names from which these ideas may flourish. You might consider ideas from the source domain and evaluate how to apply them to the target. The only thing you need to be careful is that the metaphor is partial, so stretching it to fit your situation might not always be a good idea.
• Integrity: when the source has a rich, familiar set of related parts, it will provide more integrity when applying it to your target. It will also have more integrity when the mapping between the source and the target is strong. If integrity is high, mixing other metaphors won’t weaken the overall structure.

What I found interesting on Industrial Logic’s use of the System Metaphor is that it is visible to the users of the system. If you’re taking one of their eLearning courses, you can see and interact with concepts from the music metaphor such as albums and playlists. The previous examples I’ve heard about uses of the System Metaphor were internal to the team and the business stakeholders, to improve communication. You can read more about how they discovered and applied the music metaphor here.

Conference reception – Nidaros Cathedral

The first day ended with an organ concert at the beautiful Nidaros Cathedral, followed by the conference reception with drinks and food at the Archbishops Residence and Palace Museum.

Last week marked the 10th edition of the XP 200x conference, held in Sardinia, Italy. Me and Francisco were there to present an extended version of our Lego Lean Game. Being selected as the first session on the first day of the program, we were expecting a small audience, but it turned out to be quite well attended by about 20-25 people.

We started the session a bit delayed, due to the lack of room organisation: I was a bit shocked when we arrived and the room was arranged as a normal “lecture room”, rather than the usual group tables (that we requested a week before). Projector and flipchart were not available, so it took us about 15 minutes to have everything ready to begin.

The slow start, however, did not got in the way of the overall workshop. We have designed the activities in a flexible way that allow us to adapt their length just-in-time so we still managed to cover everything we wanted without having to rush.

The first half of the workshop was mostly the same version we presented last year in Buenos Aires, with slight modifications based on feedback we got from participants. The second half, however, was mostly new and we included an activity to allow each team to come up with their own processes (rather than following ours). This turned out to be a great success! Each group came up with different ideas and, by watching the other teams perform, we had an interesting discussion about the different approaches and results. We now think that the original version is too condensed :-)

The feedback we received after the session was great and a lot of people asked us for the material to run the session themselves. Me and Francisco have a “game package” that we can share for those interested in running the game. Get in touch with us if you’re interested! You can find more photos of our presentation here, here, and here (thanks to Hubert for sharing his pictures!). The slides are also available:

We are very interested in your feedback. So, if you were at the conference or want to use the material to run the workshop, please let us know! Share your experiences and help us make it better!

XP 2009 is happening between 25-29th of May in Sardinia, Italy and I will be there attending and presenting some interesting workshops:

• The Lean Lego Game: Me and Francisco have been improving our workshop since we last presented it at Agiles 2008 in Argentina, and we will be presenting a long version (180 minutes) on Monday, May 25th. We have just a few “seats” available to participate on the session (20-24) and it will be occupied in a first-come-first-serve basis. If more people show up we have plans to try and not reject anyone, though.

• Test Driven Development: Performing Art: Emily Bache kindly invited me to present a Prepared Kata at her workshop and I will be pairing with Francisco for 30-40 minutes, programming in Ruby with RSpec/Cucumber. Should be fun to “perform” and watch the other pairs as well. Looking forward to that session on Wednesday afternoon!

My fellow ThoughtWorker Pat Kua will be there presenting a workshop as well. I will try to brush up my (lately lazy) writting skills and publish some conference reports. And hope to see you all there in Sardinia!

One of the best resources about Pair Programming to date is Laurie Williams’ book “Pair Programming Illuminated“, as well as all the research she’s been conducting on the subject. At Agile 2008 I was lucky enough to meet her personally and present my experience report in the same slot as her’s. She showed us a video that was produced to teach Pair Programming to students at the North Carolina State University.

Although targeted to the University environment, the video is great and shares some important lessons about the Do’s and Don’ts of Pair Programming. If you replace references to teacher and teaching assistant (TA) with tech lead or project manager, I’m sure most of the advices will make perfect sense.

The video is really well produced and is worth watching and sharing. Please take the time to check it out and learn from someone who’s been not only doing Pair Programming, but also teaching and publishing research on the subject.

It’s been a while since I read the 2nd Edition of “XP Explained” and I really enjoyed the emphasis on separating practices from values and principles. If you try to map the original 12 XP Practices to the new primary and corollary practices, you will notice that it’s not a one-to-one map. And that’s great! Practices are good when you are at the Shu level of learning, but they should be tailored to specific situations, and understanding the underlying principles and values is what will help you do that.

Besides Pair Programming and Test-Driven Development, most of the original XP practices are distilled in more than one practice in the second book. Refactoring and Simple Design are better exposed as Incremental Design, while the Planning Game can be recognized in a list of practices such as: Stories, Weekly Cycle, Quarterly Cycle, and even Slack. Although Coding Standards are not explicitly cited as a practice, you can see its importance when reading about Shared Code and Single Code Base. But you will miss one practice in particular from the first book: the System Metaphor.

The System Metaphor was probably the less adopted practice and usually one of the hardest to explain. If you’re able to express and design your system in a shared metaphor such as “Payroll is like an Assembly Line”, you will see the benefits of this practice shining through: communication with domain experts will be easier and the gap between domain model and implementation will become much shorter. But as it turns out, it is not easy to find a useful metaphor for every system.

If you miss this practice from XP and is looking for the underlying principles behind it, I strongly recommend reading Domain Driven Design, by Eric Evans. Striving to find an Ubiquitous Language to bridge the communication gap between developers and domain experts, and isolating complexity in a rich domain model are goals worth fighting for. In Eric’s words:

 

System Metaphors are not useful on all projects. Large-scale structure in general is not essential. In the 12 practices of Extreme Programming, the role of a System Metaphor could be fulfilled by a Ubiquitous Language. Projects should augment that language with System Metaphors or other large-scale structures when they find one that fits well. 

 

Other patterns for large-scale structure are discussed in the book, as well as a lot of other precious material. So if you still haven’t done it, go read the book!

 

For a while I’ve been planning to write on this subject. The question of whether going broad or going deep into a subject area has always been present in my life. In this post I will scratch some of my current thoughts on the subject. Feedback and other opinions are welcome!

Some Background

My parents always told me that I couldn’t be good at everything. But they’ve always been very supportive on everything I decided to do. Being a great musician, magician, and programmer was not an easy task, but that never stopped me from trying. But then I read something funny that became a good argument for a while…  

The Specialist Paradox

An specialist is someone who knows more and more about less and less, ultimately knowing everything….. about nothing!

That even made me review my resumé to remove any reference to the word “specialist” and include the word “generalist”. :-)  

Swinging the pendulum

But I forgot that you can always change the argument to take the other extreme and come up with a “Generalist Paradox”. And then I watched Kent Beck’s keynote speech last year at XP 2007 about Ease at Work. We are always trying to be the best, but then we realize how bad we are and start thinking we are the worst. A great lesson that I took from his words is that while swinging that pendulum back and forth, we never stop to think that neither of those extremes are good. Being at ease is trying to find how to stay in the middle. In our discussion, the extremes of the pendulum would be the common view that generalists are best at defining the problem or goal and specialists are best at solving the problem or “executing the plan”:

While researching about this subject, I learned that you have similar concepts in Biology (highlights are mine):

A generalist species is able to thrive in a wide variety of environmental conditions and can make use of a variety of different resources (for example, a heterotroph with a varied diet). Specialist species can only thrive in a narrow range of environmental conditions and/or have a limited diet. Organisms do not fit neatly into either group, however. Some species are highly specialized, others less so, while some can tolerate many different environments. In other words, there is a continuum from highly specialized to broadly generalist species.

We can leverage that same idea, letting go the “Us vs. Them” argument and starting to think about generalist and specialist as complementary skills. David Armano has already suggested changing the “or” to “and”, but I would dare taking it one step further…  

It’s all about context

Specialty is contextual. Anyone in my family would consider myself a specialist in programming and software development. But they don’t have a clue that Computer Science is a broad area with so many fields. Some interest me more than others, so I could say I’m a generalist at that level. But since my interest in software development and Agile Methods is greater than other fields, one could say I’m a specialist, although I wouldn’t consider myself an expert at anything :-) I can see the XP principle of Self-Similarity applied here. I think that the above picture is just a simplification of reality. There are some dots underneath the surface that you can only connect if you specialize a little bit. And I would say that the same fractal structure would appear as you go deeper and deeper into your endless search for knowledge. Sometimes you will have to go back and look broader for a while, but that’s not wasted effort. That’s why I now see value in being both a generalist and a specialist in different contexts.

A ImproveIt está deixando o mercado de serviços e consultoria em Métodos Ágeis e XP. Estava escrevendo esta resposta como um comentário e percebi que estava ficando grande demais, então resolvi dedicar um post, afinal, meus amigos da ImproveIt merecem :-)

Mais importante que vender e disseminar os valores ágeis é mostrar que eles fazem parte da sua filosofia de vida. Com essa mudança vocês demonstram tudo aquilo que é difícil de vender em XP mas que faz muito sentido para quem usa: coragem, abraçar as mudanças, transparência na comunicação e envolvimento com a comunidade.

Até poucas semanas atrás eu não conhecia o pessoal da ImproveIt pessoalmente. Tive o prazer de conhecê-los graças aos eventos de rails em São Paulo e no Rio. Agora posso afirmar com certeza que eles têm o talento e o conhecimento necessários para que o sucesso venha rapidamente.

Tenho certeza que a mudança não é uma reação aos pontos levantados pelo Vinicius. Apesar de eu mesmo ter participado e até promovido os treinamentos de Scrum do Boris, concordo com as críticas. Tanto que, se olharem meu currículo, coloco o treinamento como curso e não certificação. Prefiro olhar pelo lado positivo da mudança. Acho que a mudança de rumos está muito mais relacionada com as possibilidades que enxergam no futuro do que com o que já fizeram no passado. E é exatamente esta atitude que eu admiro. Mudar sem medo. Coragem.

Desejo muito sucesso a todos: Vinicius, Tapa, Rafael, Felipe e Leandro (o único que não conheci pessoalmente, infelizmente). Continuem produzindo produtos de qualidade assim como fizeram com os treinamentos, palestras, consultorias, posts e podcasts sobre Métodos Ágeis e XP. Um grande abraço!

Final de feriado chegando. É hora de voltar a ativa e contar como foram os eventos da última semana. Primeiro um pouco sobre o Conexão Java.

 

 

Sexta-Feira

 

Foi a primeira vez que participei do Conexão Java e gostei bastante do evento. Além de re-encontrar amigos, as palestras que assisti foram excelentes. Na sexta-feira o Alexandre Magno falou um pouco sobre Scrum e, apesar de ter precisado sair no meio da palestra, os comentários que ouvi foram todos positivos. Na sexta acabei assistindo só essa palestra, pois fiquei o resto do dia ajudando o Carlos Villela terminar seus slides (percebam que minha participação foi importante.. he he).

 

 

Sábado

 

No sábado, o keynote do CV criticou os “arquitetos de uma nota só” que preferem usar sempre a mesma ferramenta para resolver qualquer problema. Além de argumentar sobre a importância da plataforma Java vs. da linguagem Java, os tópicos levantados deixaram a platéia preparada para as próximas apresentações.

 

 

O Philip Calçado re-apresentou a palestra de arquitetura do Just Java (dessa vez sem o Paulo) e agradou bastante o público. Apesar de eu já ter assistido a palestra, foi bom para ouvir mais um pouco sobre as “arquiteturas Java do passado”. Particularmente achei muito valioso ele ter levantado temas recentes como Domain-Driven Design e DSLs.

 

 

Depois foi minha vez. Minha estréia como palestrante foi bem recebida. As pessoas que me procuraram depois da palestra me deram um feedback positivo e alguns comentários online que li (aqui e aqui) me deixaram bastante feliz com o resultado. Espero que tenha conseguido passar minha mensagem, deixando algumas sementes para discussão sobre Métodos Ágeis, XP, Scrum e Lean. Minha apresentação já está disponível para download aqui.

 

 

Após minha palestra fomos almoçar numa churrascaria e acabei perdendo a palestra do Vinícius. A última palestra do dia foi do Fernando Meyer, core developer do JBoss, sobre ANTLR e seu uso na criação de DSLs externas. Gostei pois ele mostrou os conceitos básicos de um compilador (parsing, análise léxica, análise semântica, interpretação, geração de código, etc.) e partiu para um exemplo prático de código. Dei uma ajudinha depois da palestra com um bug (essas coisas acontecem) e os slides e o código estão disponíveis no blog do Fernando Meyer.

 

 

Espero poder participar de mais eventos como esse. Se você assistiu minha palestra, deixe algum comentário (positivos ou negativos). Feedback é sempre importante e me ajudará a melhorar para as próximas apresentações. O que você gostou e não gostou da minha palestra? Você aprendeu alguma coisa? Algumas das idéias surtiram efeito no seu dia-a-dia?

 

Já faz um tempo que estou para falar das novidades e, depois das palestras em novembro/dezembro, é com orgulho que apresento o novo curso de XP na Caelum.




Eu sou um pouco suspeito pra falar bem dos cursos deles, pois não só sou amigo do pessoal de lá, como também ajudei a montar esse novo curso. No entanto, posso garantir que a preocupação deles com a qualidade do treinamento, do material, a didática e, principalmente, com o aluno é um diferencial em comparação aos cursos encontrados no mercado. É por isso que fiquei feliz com o convite para ajudar a montar esse curso e ministrar a primeira turma.




O conteúdo está muito legal e quem participar vai aprender e se divertir. O treinamento terá um enfoque bastante prático, e exigirá que os alunos programem bastante. Minha meta nessas 20 horas de curso é falar não só sobre a filosofia Ágil, os princí­pios e valores de XP, como também mostrar os aspectos técnicos e mostrar a sinergia entre as práticas da metodologia. Espero que o aluno saia do treinamento com diversas idéias novas para implantar na sua empresa.




Fico bastante feliz que novos cursos desse tipo estão aparecendo no mercado de software nacional. Isso só vem a reforçar o fato de que os Métodos Ágeis estão ganhando mais interesse no Brasil a cada dia que passa.




Quem estiver interessado em participar, é só entrar em contato com o pessoal da Caelum para mais informações ou para fazer a reserva.