Destilando

Let me guess... You would like to became a Software Architect, wouldn't you? I have seen a big push in the last inside software community by people who would like to became software architects.

A lot of them see this role as a step towards a career as a software developer. I would like to show that it is actually an illness in the software development environment.

Generally software architects aren't really software architects

Much arrogance associated with the role exists

Generalists worth more than Specialists

Also it is obvious that it is so much better to have a team of developers that can also do integration testing, than to have one or two testers in the team that will do all the integration testing of the team.

It is also clear that it is better to have a team of developers that is able to discuss possible architectures and find out an emergent solution than to have a specialist Software Architect that will make all the decisions.

Martin Fowler have already said the architects in ThoughtWorks works to increase the team's architecture skills than take their own decisions. It increase the team skills and solve the bottleneck problem. Have look:

In many ways, the most important activity of Architectus Oryzus is to mentor the development team, to raise their level so that they can take on more complex issues. Improving the development team’s ability gives an architect much greater leverage than being the sole decision maker and thus running the risk of being an architectural bottleneck. This leads to the satisfying rule of thumb that an architect’s value is inversely proportional to the number of decisions he or she makes.

The real value of software architect skills

I have strong doubts about how useful some deliverables of the software architecture discipline are, some of them are documents and diagrams with a high level vision of the system. I believe more in principles and values that I believe can replace these deliverables like:

• Effective communication between the teams is more important than documents and diagrams.
• Architectural decisions should be done by teams, for me it is obvious that an emergent decision is more valuable than a decision made by only one holy holder of knowledge.(By the way I don't believe in holders of knowledge, Jedis, and their kind )

All the successful software projects that I know was made by passionate developers

I'm sure there are some really good architects and good initiatives within the agile software communities such as the emergent architecture and the evolution architecture, but in my experience they are people who I don't believe, and I think this centralized model is more likely to fail than the decentralized model.

Software architects are really needed in enterprises where 80% of the programmers are cowboy programmers using the true XGH. These enterprises will have quality problems anyway, but it is better that the architectural decisions are made by someone who really knows what he/she is doing. In this case and in an immature market they are "a necessary evil", if you don't have a team of passionate programmers at least have a software architect who will be able to define a reasonable solution.

This is my first post (of a sequence of 3) about refactoring. I want to demystify some points in refactoring that are not evident in the software community.

The first step is to understand what is refactor. Put simply refactoring is everything that you do on code that becomes easier to understand and doesn't increase features or performance. This means if I change the code to ...

• process faster
• work in more cases
• do something new
• work as multi-threading
• fix some bug
• internationalizate the system
• And bla bla bla that changes an external behavior or performance

You are not doing refactoring, sorry if I disappointed you, but this isn't a refactoring. But if you are doing changes in the code that allow your code to be easier to understand, probably this is refactoring, for example:

• rename a method to a name more meaningful
• split a big complex method in various small simple methods
• create a class to replace some code that are redundant in the code
• move a redundant field in all sub classes to a super class
• and bla bla bla that become the code easier to understand

But second Lean, "anything you do that does not add value from the customer perspective is waste". When I'm doing some refactoring I'm not adding value to the software therefore this is a waste.

So why should I refactor if refactoring is a waste?

I understand that this is not easy to accept, but I have three reasons that can make refactoring payable.

1) Become more productive

2) Become faster to respond to changes

3) Change the enterprise culture to acquire mastery

So If you are not interested in productivity, respond to changes and mastering professional culture I think that you can have serious problems with your enterprise.

Faz muito tempo que não posto nada por aqui, isso porque cerca de 1 mês atrás me mudei para Dublin na Irlanda (Sim, a terra da Guinness), pretendo ficar aqui por um ano se tudo der certo.

Vim para a Irlanda para aprender a me comunicar (ouvir/falar/escrever/ler) na língua inglesa DE VERDADE, por tanto a partir de now I will write all my posts in English, so I can practice more (If you find some grammar error, please notify me; I'm sure I will miss a lot).

I am studing in a english school in the center of Dublin called CES (Centre of English Studies), I think this is an excellent school and I've easily seen the quality difference between anothers schools in Dublin. My course is only for 6 months and the another 6 months not are defined yet.

The contact with people from others countries is a really nice experience. I'm knowing frenchs, indonesian, italians, belgians, saudi arabians, germans, spanish, south koreans and who can't miss: Irish people. I'm traveling for some beautiful places here in Ireland. So I've uploaded my photos in Picasa at this address.

Now I'm looking for a job in Dublin. I've did some interviews with success and now I'm waiting for replys. About the technology user groups I've found some communities here like Ruby Ireland and ALT.NET Dublin.

So I will try to keep this blog updated, to comment relavant things and news!

                                                      

Acabei de ler o relatório final de pesquisa de pós-doutorado da Professora Maria Schuler da ECA USP sobre o Diagnóstico do Nível de Excelência Comunicativa nas Organizações. O relatório fala sobre muita coisa interessante, mas vou dar destaque para o tema principal da pesquisa: Os Níveis de Excelência Comunicativa nas Organizações.

Em palavras simples a excelência comunicativa nas organizações é o melhor estágio de comunicação que se possa ter. E como ela é um resultado dos indivíduos que formam organização para se alcançá-la é preciso compreender a Excelência Humana nas organizações.

A Excelência Humana é uma analise mais aprofundada das pesquisas sobre o desenvolvimento humano. Um famoso psicólogo chamado Abraham Maslow, propôs uma hierarquia de necessidade, onde as necessidades do nível mais baixo precisam ser satisfeita para antes se ter consciência das necessidades dos níveis mais altos. Representada pela imagem abaixo.

O relatório de pós-doutorado explora cada nível como uma dimensão transdiciplinar onde existe uma análise holística de várias disciplinas em convergência. Assim deixa a visão de nível de necessidade para o conceito de dimensão transdiciplinar, onde alguns níveis são re-estruturados e profundamente analisados.

Esta análise de cada nova dimensão ocorre levando em consideração quatro elementos: o indivíduo, a organização, o processo de aprendizagem organizacional e o desenvolvimento da comunicação organizacional.

Neste post vou citar apenas os aspectos da organização, pois acho interessante analisar o conceito da agilidade neste elemento. Segue abaixo o diagrama dos níveis de Excelência Humana.

Física: é a dimensão onde a organização está como foco em recursos materiais, todas as decisões tomadas são em metas de curto prazo de rápido retorno financeiro.

Emocional: é a dimensão onde a organização começa a enxergar que não trabalhar com recursos e sim com pessoas, que estas pessoas têm emoções e o foco não está em evitar emoções e sim ter pessoas que sabem administrar suas emoções e utilizá-las de forma produtiva, estabelecendo relações de confiança e ética.

Mental: é a dimensão onde a organização começa a criar reais preocupações com sobrevivência onde entram processos de planejamento diário, os fluxos começam a ser racionais, lógicos, calculáveis, previsíveis. E as decisões começam a ser menos centralizadas envolvendo um número mais de colaboradores.

Afetiva: é a dimensão onde a organização integra o maior número de colaboradores ao sucesso compartilhando os benefícios de forma justa e generosa, também cria ambientes colaborativos, de forma a despertar uma consciência coletiva nos colaboradores.

Expressiva: é a dimensão onde a organização atingiu seus objetivos materiais e neste momento a ética começa a ser incorporada na natureza da organização valores com transparência, legitimidade e justiça. Citando SCHULER: “Nesse momento do desenvolvimento, a preocupação com a justiça dos atos transcende as normas estabelecidas ou as relações de castigo ou premiação”.

Visionária: é a dimensão onde a organização reconhece que os colaboradores que já são respeitados, tratados e de forma diferenciada desde a transcendência do nível afetivo, agora não são mais vistos como um par de mãos, mas como pessoas que possuem cérebros e idéias. Agora a organização precisa que estes sejam criativos, para sobrevivência, resolução de problemas, inovação e descoberta de conhecimento.

Integradora: é a dimensão onde a organização e colaboradores alinham missão, visão, vocações e o sentido de trabalhar; nesta dimensão o objetivo é criar um grupo unido, consciente de sua responsabilidade com a sociedade e o meio ambiente. Neste ponto cada decisão de cada colaborador reverbera os valores e a missão da empresa.

Bem o relatório é muito maior que este post, e eu fiz resumo porco muito simplificado de apenas um dos elementos estudados no trabalho, aconselho fortemente ler o trabalho disponível aqui, principalmente às analises em relação ao elemento: O Indivíduo.

Agora peço que preste atenção a dimensão mental, observem as palavras “processos de planejamento diário”, “fluxos calculáveis e previsíveis”, “decisões menos centralizadas” e “fluxos racionais”, isso lembra alguma coisa? Para mim lembra muito forte a idéias de agilidade.

Interessante ressaltar que a pessoa que escreveu sobre a dimensão metal nem sabia o que era Agilidade, entre tanto citou algumas características ágeis nesta dimensão, relacionadas no quadro abaixo.

Entendo que para conseguir aplicar um método ágil é imprescindível que a organização já tenha passado pelos níveis: Físico e Emocional. Isso explica a dificuldade da adoção de práticas ágeis em algumas organizações, pois estas organizações não estão realmente preparadas para transcender para a dimensão mental. Por isso é muito importante entender para quem você está vendendo agilidade.

A agilidade é a dimensão onde a organização consegue ter atitudes mais racionais. Como podemos ver no diagrama existem dimensões acima da Mental e que vejo exemplos como a Semco, a Toyota e a iniciativa na Visa, onde existe algo muito maior que os princípios e valores da agilidade.

Eu não sei o que está acima da agilidade, mas sei que ainda estamos no meio do caminho.

Estive esta semana do Coding Dojo no IME-USP, junto com Hugo Corbucci e Mariana Bravo. Resolvemos fazer o problema Poker-Hand em Ruby, que consiste em: dado duas mãos de poker o software precisa dizer quem ganha.

O Hugo sugeriu que começássemos o programa pela Classe PokerHand, e depois fossemos programando as cartas, os naipes e assim por diante. A ideia se resume em criar toda a infra-estrutura para o programa antes de começar a implementar o núcleo (que seriam as regras do Poker) do mesmo.

Sugeri que não fizéssemos isso, mas que começássemos pela classe PokerGame (que mais tarde virou PokerRules), pois desta forma começaríamos descrevendo as regras, atacando o núcleo do problema primeiro e trazendo uma abordagem mais orientada ao domínio do problema.

Isso gerou algumas discussões, mas resolvemos tentar o que eu havia sugerido, e então implementamos todas as regras na classe PokerGame, assim esta classe já sabia dizer que “dois pares” é menor que “um trio”, que “Flush” é menor que um “Full House” e assim por diante.

Depois aplicamos os mesmos princípios às cartas e depois aos naipes, assim já tínhamos uma classe que sabia toda a regra do Poker e que tinha todo o conhecimento necessário para fazer os desempates.

Fomos para o PokerMatcher, esta classe tinha por objetivo reconhecer que uma determinada PokerHand era um “Flush” se tivesse uma sequência de números nas cinco cartas da mão.

Começamos o PokerMatcher, não criamos uma PokerHand, dissemos que uma PokerHand é um list de cinco cartas, isso é discutível, mas enfim optamos por isso. Implementamos a PokerMatcher até reconhecer “um par”.

E na retrospectiva eles me mostraram uma outra solução para o problema, que surgiu naturalmente em um outro dojo que eles fizeram. Percebi que esta outra abordagem se apresenta diferente, quando começa-se implementando as cartas e depois a mão até chegarmos ao seguinte ponto:

Neste ponto, eles pensaram em atribuir um sistema de pontuação para cada uma das mãos onde baseado em um mapa de hexadecimal, cada dígito do número hexadecimal equivale a uma das jogadas de poker ordenado da direita para esquerda. O quadro abaixo ilustra esta forma:

Enquanto eles pensaram em criar uma fórmula matemática para pontuar cada uma das mãos, eu pensei em não pontuar mas descrever as regras um uma classe e criar um matcher para avaliar quem vence.

Acredito que nenhuma das soluções está certa e nenhuma das soluções está errada, mas que ambas possuem vantagens e desvantagens e que uma das causas que corroboraram nestas diferentes abordagens foi devido as distintas formações acadêmicas dos participantes do dojo.

Eu faço Sistemas de Informação, e eles fizeram Ciências da Computação. O curso de ciências da computação é um curso muito mais matemático do que curso de sistemas informação, pode-se observar pelas grades dos cursos. Segue abaixo um comparativo simplificado:

Para eles foi natural a utilização de um mapa hexadecimal para pontuar a mão de poker, enquanto para mim esta ideia nem passou pela minha cabeça, pois não fazia o menor sentido pontuar a mão, e sim fazer um matcher com as regras do jogo. O interessante foi a experiência de ver a diferença dos raciocínios.

Este tipo de discussão é o que, para mim, mais agrega valor em uma sessão de Coding Dojo. Sempre devemos tentar conhecer novos mindsets, e quanto mais diferente, melhor. Pois quanto mais opções você conhecer para resolver um problema, mais bem preparado você estará para resolver o mesmo.