AgileAndArt

This article is originally published in the ACM Digital Library for the ONWARD ’11 Proceedings of the 10th SIGPLAN symposium on New ideas, new paradigms, and reflections on programming and software. I’d like to specially thank the co-author and friend Joe Yoder and Richard P. Gabriel for all patience and good advices with this work.

História

Em agosto de 1993, Kent Beck e Grady Booch patrocinaram um retiro na montanha, onde um grupo de pessoas chegou a um consenso sobre os fundamentos em padrões de software. Ward Cunningham, Ralph Johnson, Ken Auer, Hal Hildebrand, Grady Booch, Kent Beck e Jim Coplien se basearam fortemente nas ideias de Alexander e suas próprias experiências, formando um casamento entre objetos e padrões. O grupo concordou que estávamos prontos para construir, sobre as fundações do trabalho de Erich Gamma sobre padrões orientados a objetos, e usar esses padrões da mesma forma que Christopher Alexander usa seus padrões para planejamento urbano e construções arquitetônicas. O encontro do grupo se deu ao lado (side) de um monte (hill), daí o nome Hillside.

Desde então, o Hillside Group se tornou uma organização educacional sem fins lucrativos, que patrocinou e ajudou a organizar várias conferências (Plop Conference, EuroPlop, ChiliPlop, KoalaPlop, Mensore PLoP, SugarloafPLoP, e UP97), além de ter sido responsável pela edição e publicação da série de livros “Pattern Languages Of Program Design”.

A conferência

Os eventos do PLoP são encontros bastante diferentes das conferências tradicionais que estamos acostumados. Normalmente, quando vamos a uma conferência, ficamos quase o dia todo assistindo palestras, normalmente ministradas por pessoas com bastante experiência. Nesses eventos, temos poucas oportunidades de conhecer e conversar com os outros. Isso até acontece, mas quase sempre de forma rápida e superficial.

Já no PLoP, a interação entre os participantes é bastante intensa e rica. Normalmente o evento dura 3 dias, durante os quais você realmente conhece as pessoas que estão lá. As refeições e o hotel já fazem parte do pacote do preço da conferência, então você acaba tomando café, almoçando e jantando com esse grupo. Como consequência disso, temos a oportunidade de manter conversas longas e produtivas com os participantes.

Além das refeições fartas e deliciosas, o PLoP também inclui várias dinâmicas e jogos em grupos (games), cujo objetivo é aproximar os participantes, motivando e estreitando as relações pessoas entre todos. Os jogos são sempre divertidos, engraçados, tornando o ambiente mais seguro, informal e, principalmente criativo. Pode parecer um detalhe, mas esses jogos são fundamentais para o sucesso e

qualidade do evento.

Design Patterns (Padrões de projeto) – meio óbvio né… Os assuntos que discutimos são quase sempre relacionados com desenvolvimento de software, com foco principal em padrões. Poucos desenvolvedores se dão conta, mas boa parte do que conhecemos sobre técnicas e boas práticas em desenvolvimento de software vieram de alguma maneira da comunidade de padrões. Apenas para citar alguns exemplos:

• Testes com dublês (stubs, mocks, etc)
• Scrum nasceu de padrões
• Métodos ágeis nasceram na comunidade de padrões
• Padrões de arquitetura
• TDD (Test Triven Development)
• Refatoração de código
• Domain Driven Design (DDD)
• Model Driven Design (MDD)

Submissão dos artigos

Para participar do PLoP, é preciso submeter para a conferência, alguns meses antes, uma proposta de artigo. Se o seu artigo estiver num nível que considerado adequado pelos avaliadores, você é aceito para o chamado processo de shepherding. O termo shepherd em inglês significa pastor – a ideia é que você será conduzido por um “mestre” no processo de escrita do seu artigo. Para cada autor, são escolhidos 1 ou 2 shepherds, que lerão o artigo atentamente e farão várias sugestões de melhoria.

Esse processo dura em torno de dois ou três meses. Durante esse tempo, você troca várias mensagens com os shepherds, mandando novas versões melhoradas do artigo. No meu caso, foram 4 iterações. O artigo que eu escrevi era sobre quatro novos padrões para introduzir novas ideias. Minha ideia era adicionar novos padrões ao catálogo original da Linda Rising e Mary Lynn Manns (livro Fearless Change). O artigo era uma evolução da minha tese de mestrado.

Ninguém melhor do que as próprias Linda e Mary Lynn para me ajudarem a escrever esses padrões, por isso elas foram escolhidas como minhas shepherds. A ajuda que obtive delas foi incrível, o que me possibilitou ter um artigo num nível adequado para ser aceito para a conferência. Após o processo de shepherding, você precisa enviar o artigo novamente para avaliação. Novamente, os avaliadores lêem o artigo e decidem se ele é adequado para ser trabalhado na conferência, num processo que eles chamam de Writers Workshop.

Writers Workshop

O “carro chefe” das conferências PLoP são o que chamamos de Writers Workshop (Oficina dos Escritores). O conceito surgiu em comunidades de poetas, que se encontravam frequentemente para debater e aprimorar suas poesias. A dinâmica do Writers Workshop consiste na troca de experiência entre vários autores. Quem trouxe essa ideia para o mundo da computação foi o cientista Richard P. Gabriel. Ele escreveu um livro sobre o assunto, descrevendo detalhadamente como conduzir a oficina.

Funciona basicamente assim: vários autores de artigos formam um grupo (normalmente de umas 10 pessoas). Durante os três dias do PLoP, esse grupo se encontra várias vezes. Em cada encontro eles escolhem um dos artigos para aprimorar. O autor do artigo deve obrigatoriamente estar presente, mas seu papel é apenas de ouvinte. Os outros fazem comentários, dando sugestões positivas e práticas de como melhorar o artigo. O autor anota essas considerações, para posteriormente aplicá-las a uma nova versão do artigo.

Uma regra importante na oficina é a de que o artigo tem que falar por si só, ou seja, o autor não pode ficar dando explicações para os outros de coisas que deveriam estar claras no artigo. Se posteriormente alguém for ler o seu artigo, você não estará presente para dar suas explicações. Por isso, é importante que todas as ideias que você quer transmitir estejam claras no artigo.

No final, o resultado extremamente satisfatório. O objetivo da comunidade de padrões é criar uma vasta literatura sobre soluções de problemas, que se mostraram eficazes em alguns contextos e que podem servir de guia para que outros apliquem as mesmas soluções e obtenham sucesso em seus projetos. Normalmente um padrão não é algo cabulosamente complicado, mas sim coisas simples, porém muito poderosas se aplicadas corretamente. Um fator importante que torna um padrão poderoso é a forma como ele é documentado. Autores de padrões devem tomar o cuidado de documentar muito bem um novo padrão, de maneira que ele seja amplamente compreendido. O Writers Workshop é fundamental para que texto final de um padrão seja lapidado ao extremo, tornando conciso, objetivo, prático e eficaz.

Minha participação

Nesse ano, eu participei do PLoP como autor de um artigo junto com o Professor Fabio Kon. O líder do meu grupo no Writers Workshop foi o próprio Richard Gabriel, ou seja, o cara que inventou a oficina! Foi uma surpresa maravilhosa tê-lo como um dos conselheiros para o meu artigo. Além do Richard, outros 6 autores faziam parte do grupo e ouvi comentários extremamente positivos e importantes para melhorar o artigo.

Para aqueles que tiverem interesse, podem ler a versão preliminar do artigo aqui. Durante os próximos meses, trabalharei para incorporar as sugestões obtidas na oficina de escritores. Essa nova versão será enviada para os organizadores da conferência, que farão uma avaliação final e, caso o artigo esteja satisfatório, será publicado na biblioteca digital da ACM.

Veja outras fotos do PLoP 2011

OOPSLA

Em 1985, um grupo de 4 pioneiros em programação orientada a objetos decidiu organizar nos EUA uma conferência sobre programação de sistemas orientados a objetos. No grupo estavam Adele Goldberg, Tom Love, David Smith, and Allen Wirfs-Brock, e a conferência foi chamada de OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications). A primeira OOPSLA aconteceu no Hotel Marriott, em Portland, Oregon, em novembro de 1986. Cerca de 600 pessoas participaram, 50 artigos foram apresentados e os participantes ouviram sobre Smalltalk, Lisp, Flavors, CommonLoops, Emerald, Trellis/Owl, Mach, Prolog, ABCL/1, prototypes, e programação concorrente e distribuída de pessoas como Danny Bobrow, Gregor Kiczales, Rick Rashid, Andrew Black, Dave Ungar, Henry Lieberman, Ralph Johnson, Dan Ingalls, Ward Cunningham, Kent Beck, Ivar Jacobson e Bertrand Meyer.

Essa gama enorme de tópicos e pesquisadores definiu o tom da conferência, que se tornou forum para alguns dos principais desenvolvimentos de software das últimas duas décadas. Foi na OOPSLA que nasceram coisas como cartões CRC, CLOS, Padrões de Projeto (Design Patterns, Self, métodos ágeis, arquiteturas orientadas a serviço (SOA), wikis, UML, TDD, refatoração, Java, compilação dinâmica, programação orientada a aspectos, só para citar algumas delas. Nem sempre falando sobre objetos, mas nunca deixando o assunto de lado, a conferência cresceu de 600 para 2500 participantes no seu pico, sendo ainda forte com cerca de 1300 pessoas mesmo depois do surgimento de uma série de conferências sobre padrões, Eclipse, EclipseCon, Agile e AOSD.

No final dos anos 90 – com o sucesso de Smalltalk e Java nos negócios e C++ na engenharia – OO se tornou amplamente adotada e a OOPSLA mudou de uma conferência que trabalhava para tornar OO prático e compreensível para trabalhar nos problemas do mundo sempre mutante da computação, tanto na inventando novas técnicas e tecnologias quanto melhorando e expandindo teorias. O que permaneceu foi a paixão por inovação e o hábito de criar comunidades.

Onward!

No começo dos anos 2000, algumas pessoas da OOPSLA sentiram que a conferência se beneficiaria muito se fosse criada uma nova trilha de publicação de artigos focados em ideias inovadoras além de OO, e em formatos de artigos que normalmente não seriam aceitos na OOPSLA. Nasce então a Onward!, coordenada por Richard Gabriel. Onward! foi a primeira conferência patrocinada pela ACM a dar voz a “artigos ideias” no âmbito da aceitação acadêmica. Muitas outras conferências seguiram esse modelo depois.

SPLASH

Na metade dos anos 2000, ficou claro que a estrutura de organização da OOPSLA e Onward jutas precisavam ser refatoradas, não apenas para que ambas existissem ao mesmo tempo, mas também para fornecer a possibilidade de incluir novas trilhas de artigos, mantendo a conferência nova e moderna. Depois de vários debates entre as comunidades, ficou finalmente decidido criar um guarda-chuvas de conferências: assim nasceu a SPLASH, a conferência da ACM em Sistemas, Programação, Linguages e Aplicações: Software para a Humanidade.

Desde 2010, a SPLASH tem mantido e administrado a OOPSLA, Onward! e uma variedade de outros eventos, como o Simpósio de Educadores, Workshop de Experiências, Painéis, etc. OOPSLA é hoje “apenas” a trilha técnica de artigos de pesquisa de alta-qualidade, que foi desde o início o coração desse conferência. Ao mesmo tempo, a OOSPLA aumentou o escopo de tópicos muito além de OO, aceitando hoje uma enorme variedade de artigos relacionados a programação. Ao criar a SPLASH como um guarda-chuvas de conferências, a comunidade pode agora sustentar novas trilhas de artigos que eventualmente não cabem na OOPSLA, mas que ainda sim são relacionados. Assim, permite-se o espaço para inovação, assim como aconteceu com a Onward!

E eu com isso?

Esse ano (2011), eu terei o privilégio de participar da SPLASH pela primeira vez (algo que eu já gostaria de ter feito há bastante tempo

A SPLASH tem um programa de Estudantes Voluntários, onde nós, estudantes, podemos participar da conferência de graça em troca de algumas horas de trabalho para ajudar na organização. Eu me inscrevi nesse programa de estudantes voluntários e fui aceito.

Além disso, eu tive dois artigos aceitos: um na Onward! e outro na PLoP (outra conferência que faz parte do guarda-chuvas da SPLASH). Para esses dois artigos, participarei do que eles chamam de Writers Workshop (Workshop de Escritores). O objetivo é trabalhar durante várias horas junto com os maiores (acreditem, são os maiores mesmo!) especialistas da área e anotar sugestões de melhorias para os artigos, que posteriormente farão parte das publicações científicas da conferência. Acima de tudo, é uma oportunidade maravilhosa de aprender muito e conhecer muita gente legal.

Depois que os artigos ficarem prontos (e bem melhorados após os comentários das pessoas na conferência) eu publico aqui nesse Blog.

Próximos passos

Ao longo da próxima semana, farei (na medida do possível alguns posts aqui nesse blog contando um pouco mais sobre essa conferência incrível. Farei, como de costume, várias fotos e, talvez, alguns vídeos. Dessa forma, consigo compartilhar um pouquinho dessa experiência quem não pôde ir desta vez!

 
Utilizando a Linguagem Ubíqua criamos um modelo de domínio através do Projeto Dirigido pelo Modelo (Model Driven Design – MDD). A idéia por trás de MDD é a de que o seu modelo abstrato deve ser uma representação perfeita do seu domínio. Tudo que existe no seu negócio deve aparecer no modelo. Só aparece no modelo aquilo que está no negócio.

Em um time que cria software temos de um lado os especialistas de negócio e de outro os desenvolvedores e arquitetos. Num processo ágil defendido pelo MDD a criação do modelo abstrato deve ser feita em grupo, com todas as pessoas juntas. Se arquitetos e analistas de negócio criarem o modelo sem a participação dos programadores, corre-se o risco de criar um modelo que não é implementável ou que usará uma tecnologia inadequada. Da mesma forma, se os programadores codificarem sem se basear num modelo consistente, provavelmente desenvolverão um software que simplesmente não serve para o domínio. Em DDD, parte das pessoas que modelam o domínio são necessariamente pessoas que colocam a mão em código (Hands-on Modelers). Se os programadores não se sentirem responsáveis pelo modelo ou não entenderem como o modelo funciona, então o modelo não terá relação alguma com o software produzido por essas pessoas.

O processo de maturação de um sistema desenvolvido usando MDD deve ser contínuo. O modelo servirá de guia para a criação do código e, ao mesmo tempo, o código ajuda a aperfeiçoar o modelo. O contato contínuo com o código trará insights aos programadores, que irão refatorar o código. Essa refatoração deverá ser feita não só no código, mas também no próprio modelo.

It was a great event and I’m very happy to be part of it. QCON was awesome! I hope you enjoy the pictures

No mês passado participamos de uma atividade promovida pela ThoghtWorks Brasil em Porto Alegre e organizada pelo Carlos Villela (CV). Eles aproveitaram a ocasião do FISL12 para organizar esse pequeno evento no confortável escritório que fica dentro do campus da PUC-RS. Foi pequeno em relação ao número de participantes (acho que éramos em uns 30), mas enorme em divertimento e aprendizado.

A brincadeira era uma espécie de Dojo, com regras um pouco exóticas. A ideia original foi do Nat Pryce e do Ivan Moore, e eles chamaram de Scrapheap Challenge, por causa do programa de TV, mas eu resolvi re-batizar para Dojo Ojod (um palíndromo de Dojo ao contrário), pois foi exatamente assim que o CV definiu (e que eu concordo muitíssimo): um Dojo ao contrário.

Vamos lembrar que o objetivo principal do Coding Dojo é aprender, num ambiente amistoso e divertido. Nesse quesito o Dojo Ojod é bem semelhante ao Dojo Randori (a mais tradicional modalidade de Dojo). O que muda é que no Dojo Randori temos que fazer TDD, seguir passos de bebê e escrever o melhor código possível, refatorando, deixando ele elegante. No Dojo Randori não temos o objetivo de resolver o problema proposto. Já no Dojo Ojod o objetivo principal é resolver o problema, só que de uma maneira não convencional. Na verdade, a regra é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código que pudermos. Vale usar qualquer coisa, desde scripts nojentos até ferramentas prontas na Web, planilha de Excel, tudo que tem de mais abominável em matéria de desenvolvimento de software. O importante é favorecer a reutilização.

Aqui vão as instruções de como organizar um Dojo Ojod você mesmo:

1. Exponha a lista de problemas (veja os exemplos de problemas abaixo). Normalmente é bem ter umas 5 opções.
2. Cada pessoa escolhe que problema quere fazer. Dessa forma todos se dividirão em alguns grupos.
3. O ideal são grupos de 4 a 6 pessoas. Tente fazer com que isso aconteça, re-arranjando as pessoas caso seja necessário.
4. Cada grupo irá trabalhar isoladamente por 2 horas (cada grupo pode se sub-dividir como preferir se achar melhor).
5. Durante o trabalho, lembrem-se de que o objetivo principal é resolver o problema com o maior número possível de gambiarras e escrevendo o mínimo de linhas de código.
6. Passadas 2 horas, cada grupo irá apresentar para os outros a solução encontrada (acreditem, isso será muito engraçado!).

Um dos requisitos mais difíceis para esse tipo de Dojo é justamente criar problemas interessantes de serem resolvidos nesse tempo (2 horas). Vou passar aqui a lista dos problemas que tivemos na ThoughWorks:

O grupo que eu participei resolveu o problema número 3 (a música mais sortuda da cidade). Para quem está curioso, veja a solução no meu github e ouça um trecho dessa música maravilhosa.

Essa dinâmica de Dojo nos faz perceber como existem infinitas maneiras de se resolver um problema e como podemos re-utilizar soluções prontas, agrupando-as da maneira adequada, sem a necessidade de escrevermos muito código.

Organize você um Dojo desses na sua comunidade e deixe o seu comentário aqui de como foi o resultado. Se conseguirem inventar novos problemas, por favor, me conte também

Não deixe de ler uma descrição mais detalhada do Scrapheap Challenge no site do Nat Pryce.

I’ve just read an excellent article from the Harvard Business review magazine: “How Pixar Fosters Collective Creativity”. The article is written by Ed Catmull, the cofounder of Pixar and the president of Pixar and Disney Animation Studios. He describes how is the creation process of Pixar movies, and how this process changed and evolved since Toy Story, the first movie from Pixar.

There are some points in the article I’d like to highlight.

What is creativity

• Creativity involves a large number of people from different disciplines working effectively together to solve a great many problem
• A movie, like a software, is not only a single idea. Movies and softwares contains literally tens of thousands of ideas.
• The leaders sort through a mass of ideas (and possible designs in software) to find the ones that fit into a coherent whole, which is very difficult task
• What is the key to be able to recover from fail? Talented people! And such people are not easy to find. What is equally though, of course, is getting talented people to work effectively with one another

The roots of pixar culture

• Smart people are more important than good ideas
• It is OK to hire people who are smarter than you
• In the process of creating a new movie (software), the first versions are very rough, but they give a sense of what the problems are, which in the beginning are many. Then we have to iterate, and each version typically gets better and better.
• If you give a good idea to a mediocre team, they will crew it up; if you give a mediocre idea to a great team, they will either fix it or throw away and come up with something that works.
• Deeply ingrained in Pixar culture is that everything they touch needs to be excellent.

Power to the creatives and a peer culture

• Creative power in a film (software) has to reside with the film’s creative leadership
• The creative vision propelling each movie (software) comes from one ow two people and not from either corporate executives or a development department (this point is similar to what Fred Brooks says about conceptual integrity. I don’t completely agree with that. I also like Richard Gabriel’s vision, that there are many hidden co-authors and the things designed themselves)
• Good artists understand the value of limits. I completely agree with this. This makes me remember a phrase from my theater director. He said that “an actor has to have the German discipline with the Brazilian creativity both at the same time. Hot side with cold side”.
• Everything in Pixar is done by peer reviewing. This works because all the participants have come to trust and respect one another

Technology + Art = Magic

• Walt Disney believed that when continual change, or reinvention, is the norm in an organization and technology and art are together, magical things happen
• Showing unfinished work each day liberates people to take risks and try new things because it doesn’t have to be perfect the first time
• At Pixar, we believe in this swirling interplay between art and technology and constantly try to use better technology
• Technology inspires art, and art challenges the technology
• The most efficient way to deal with numerous problems is to trust people to work out the difficulties directly with each other

Common wisdom says that science and art are entirely different beasts; moreover, a similar source of wisdom tells us that science is valuable to society while art is a luxury. Why else would schools drop art from their curricula over the past 20 years? But artists and scientists approach their work in similar if not identical ways.

This presentation was created by Richard P Gabriel and presented at IME-USP – São Paulo on 31/Mar/2011 sponsored by CCSL

Richard’s Bio

Richard P. Gabriel (Ph.D., Stanford University, 1981; MFA Creative Writing (Poetry), Warren Wilson College, 1998; ACM Fellow) performs programming language, creativity, and software engineering research at IBM Research. He is the author of five books. He played lead guitar in a rock ‘n’ roll band for 20 years.

Conceptual integrity arises not (simply) from one mind or from a small number of agreeing resonant minds, but from sometimes hidden co-authors and the things designed themselves.

This presentation was created by Richard P Gabriel and presented at IME-USP – São Paulo on 30/Mar/2011 sponsored by CCSL

CCSL sponsors the coming of two big names of Computer Science to Brazil. They will be here next week (March 30th, 31th), at the Event “Better Science Through Art” with Joe Yoder and Richard Gabriel. The event will be awesome and FREE!

Common wisdom says that science and art are entirely different beasts; moreover, a similar source of wisdom tells us that science is valuable to society while art is a luxury. Why else would schools drop art from their curricula over the past 20 years? But artists and scientists approach their work in similar if not identical ways.

In this event, Richard P. Gabriel and Joe Yoder, two big names of Computer Science, bring us details about why science and art should walk together in the same path, taking students and professors to think about the universities current research and work method.

Richard will give a talk about Designed as Designer - why conceptual integrity arises not (simply) from one mind or from a small number of agreeing resonant minds, but from sometimes hidden co-authors and the things designed themselves. Joe will also talk “When Should You Consider Meta-Architectures? and the use of Meta to Scale”

The event is FREE and will be on March 30th and 31th – from 2pm at no IME-USP, Rua do Matão, 1000 – Giglioli room

More information in the event website

Richard’s Bio

Richard P. Gabriel (Ph.D., Stanford University, 1981; MFA Creative Writing (Poetry), Warren Wilson College, 1998; ACM Fellow) performs programming language, creativity, and software engineering research at IBM Research. He is the author of five books. He played lead guitar in a rock ‘n’ roll band for 20 years.

Joe’s Bio

Joseph Yoder (Founder and Chief Architect, The Refactory, Inc.; Hillside Board President; ACM Member) is a pattern enthusiast and an author of Big Ball of Mud; he programs adaptive software, runs a development company, and consults top companies on software needs. He is an amateur photographer, motorcycle enthusiast, and enjoys dancing samba. Extended Bio